Re: [QGIS-Developer] GeoPackage - where are we -where do we go

[Nyall Dawson]

On Tue, 30 Jun 2020 at 15:52, Valérian Lebert  wrote:
>
> Hi,
>
> For my information, what is the downside of using spatialite instead of 
> geopackage apart from the weight of the file ? Are these issues an issue with 
> spatialite also?

yes -- it's coming from the underlying sqlite format which is used by
both spatialite/geopackage

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] GeoPackage - where are we -where do we go

[Valérian Lebert]

Hi,

For my information, what is the downside of using spatialite instead of
geopackage apart from the weight of the file ? Are these issues an issue
with spatialite also?

Regards
Valérian

Le ven. 8 mai 2020 à 11:30, Matthias Kuhn  a écrit :

> Hi list,
>
> I wondered about the state of GeoPackage. Personally, cince it has been
> introduced to qgis and evenmore since it has been selected as the default
> format, I have never grown to fully and completely.
>
> I do not want to trigger a evangelical discussion here. I'd like to see
> where we are and what we can reasonably do to have a default file format
> which can be recommended with no bad feelings.
>
>
> Here follow a couple of observations over the years, some of them
> properties of the specs I believe:
>
>
> * The fid requirement
>
>   I sometimes want my features to be identified by uuids or others. They
> also tend to accumulate if derived datasets are created (through processing
> etc). If I need some pseudo stable primary key there is a rowid builtin
> into sqlite, we don't need a second one.
>
>   Possible mitigation: alter the ogr implementation. possibly alter the
> standard (required?)
>
> * The modification on r/o open
>
>   Has caused too much pain on git.
>
>   Possible mitigation: a) switch to journal mode=delete (not an easy
> option because of https://issues.qgis.org/issues/15351) b) only switch to
> wal mode when layers are put into edit mode (I have strong doubts this is a
> safe thing to do)
>
> * The network share freeze
>
>   Our default file should play nicely with (windows) network shares. It's
> clear to everyone that we can't expect concurrent writes. But it should
> "just work" for concurrent read by many.
>
>   Possible mitigation: switch to journal mode=delete for network shares
> (we are looking into this)
>
> * The wal file appearing next to the file
>
>   It is confusing to newcomers and looks almost like a sidecar file. I
> would care less if it was put into some system cache folder instead of just
> into my data folder. Or at least if it was a hidden file.
>
>   Possible mitigation: switch to journal mode=delete (not an easy option
> because of https://issues.qgis.org/issues/15351)
>
> * The couple of corrupted files I have received over the years which
> could only be repaired by a command line "dump contents as sql and execute
> into new file"
>
>   I have not found a way to reproduce this. Some of them were produced by
> older qgis versions making it easy to violate foreign key constraints and
> hard to recover. This has been fixed.
>
>   Possible mitigation: offer a "repair" option in qgis. Through processing
> or "on the fly" upon detection.
>
> * Default value magic replace values on insert (with no possibility to
> pre-evaluate them)
>
>   E.g. a global sequence like on postgres would be nice. Can be worked
> around through default values in qgis though.
>
>   Possible mitigation: a)add it as a feature to sqlite. b) use qgis
> default values. c) live with it.
>
> * The requirement for a single geometry column per table
>
>   I just don't see a good reason to forbid that
>
>   Possible mitigation: a) alter the standard. b) ignore the standard and
> patch the ogr implementation.
>
>
> I wonder how others feel about these topics.
>
>
> - Are there more pain points I forgot to list?
>
> - Do you see more approaches to mitigate these problems?
>
> - Is someone already working on these issues?
>
>
> It would be great to have a standard file format that we can fully trust.
> Let's make a reality check if GeoPackage can be this format.
>
> Best regards
> --
> Matthias Kuhn
> matth...@opengis.ch
> +41 (0)76 435 67 63 <+41764356763>
> [image: OPENGIS.ch Logo] 
> ___
> 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-tr] Concerns about translations and QGIS overall credibility

[Stefano Campus]

ciao to everyone, let me show you the Italian situation.

1) the use of QGIS in Italy, especially in the Public Administration,
continues to spread more and more.
When I say "Public Administration" I do not mean only the Ministries or
other big public organizations, but above all small Municipalities also
with a few hundred inhabitants, whose technicians begin to see the
possibility of using for many subjects no longer the CAD but (Q)GIS.
During the Central Italy 2016 Earthquake, we installed QGIS in more than
200 Municipalities, in order to manage the complex phase of post-earthquake
surveys of private buildings.
Well, I assure you that if QGIS had been only in English, the chances that
the technicians and volunteers would use QGIS, would have been very low.
The fact that the default language in QGIS is the local one is a
consolation and safety for the user.

2) matteo ghetta, paolo cavallini and I are the coordinators of the Italian
translation team. There are more than 60 people registered in Transifex,
but there are very few active ones.
The work flow is this: anyone can translate, but only one is the reviewer
(me). This helps to have a unique (or almost) translation style and allows
revisions and corrections on strings to spread immediately over all the
other similar ones in the various versions of QGIS available.
This is the reason why I don't like having strings of versions 3.4 and 3.8
in Transifex: I work on "All resources" and therefore when I make massive
corrections I have errors due to the presence of these strings that are no
longer editable.

3) In Italy the interest in the translation of QGIS (GUI, site and
documentation) is high; As part of summer webinars organized by the
GFOSS.it association, on July 9 I will hold a short webinar on tricks and
good practices for translating in Transifex and about twenty people have
already registered.

In conclusion, I believe that although there are sometimes obvious errors
in the translations that make the string incomprehensible, it is necessary
to persevere and continue to improve and push users to report errors or
omissions.
The choice of a single reviewer greatly limits the possibility of errors,
even if the various evolutions of the resources of QGIS in Transifex has
led to having thousands of strings that had already been revised to be
again unreviewed, frustrating the work of months.
But that's okay; Transifex is exceptional even if it is hateful not to have
the context in which the string is used.
And please don't make English the default language.

thank you and forgive my Italianglish: when I translate QGIS from English
to Italian I am more accurate :-D

s.

Il giorno mar 30 giu 2020 alle ore 00:20 Alexandre Neto <
senhor.n...@gmail.com> ha scritto:

> Transifex Webtranslation page for QGIS is on
> https://www.transifex.com/qgis/
>
> Hi,
>
> I have been looking into the Portuguese translations of the GUI and the
> Docs, and I got really scared. Many translations were done completely out
> of context, making it very hard to read or understand what was
> originally written in English, even if you are familiar with the
> terminology.
>
> I don't know how other languages are going, and if you face the same
> problems. In Portugal, we have a very small community. Because of that,
> translation efforts are not really coordinated or even reviewed in most
> cases.
>
> Now, the biggest problem is that I think this deeply affects QGIS
> credibility. When you install QGIS, it defaults to the machine's locale,
> and many users don't even know how to change it (seen it in several
> courses). This means that many people will only know the badly translated
> version of QGIS in their native language... and It looks bad.
>
> In training, people sometimes make fun of the translations. I always
> enforce the idea that the translation work is fully done by volunteers in
> their spare time, but I am afraid if for some people it just looks like the
> full application was done by volunteers and hobbyists.
>
> So, I wanted to know if more of you face the same issues. If so, would it
> be wiser to default the language always to English and let the user find
> out how to change to his language if he wants to?
>
> Thanks,
>
> Alexandre Neto
>
> PS: Sorry for the cross-posting
>
>
> ___
> QGIS-Translators mailing list
> qgis...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-tr
___
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-tr] Concerns about translations and QGIS overall credibility

[Falk Huettmann]

Dear All,

thanks,
if I may express that here:

for QGIS I am probably less concerned about an off comma and strange-funny
term
in the major EU languages (most of them are techno-anglicised anyways) .

I rather care for text software versions of QGIS in Suaheli, Arab
languages, Pidgin, Hindi, Mandarin and Esperanto.

I believe that's where much of the QGIS power really sits, and for
applications and 'markets'.

Please do not forget those,
instead a focus just on a few  upset vanity users in Germany etc.

Just my view and from experience.

With kind worldly open source regards

  Falk Huettmann


On Mon, Jun 29, 2020 at 2:38 PM Nyall Dawson  wrote:

> On Tue, 30 Jun 2020 at 08:20, Alexandre Neto 
> wrote:
>
> > So, I wanted to know if more of you face the same issues. If so, would
> it be wiser to default the language always to English and let the user find
> out how to change to his language if he wants to?
>
> What about a predefined allow list of "high quality translations"? And
> we'd only default to using the local language IF it's part of this
> predefined list...
>
> 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
___
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-tr] Concerns about translations and QGIS overall credibility

[Werner Macho]

Hi!

While we've got a lot more languages and translations now I share your
concerns too.
After all (and you alreade mentioned it) it is all volunteer work.
There is still the option of reviews on transifex, but I am a bit
concerned that translations AND reviews would be too much for some
languages.
The idea of having english as default language and let the user decide
if he wants to switch to the native language (probably with a warning
that the translation is done by volunteers) is a good one, but what to
do with the people who do not (or only a little) speak english?

Having good translations is hard work.

regards
Werner

On Tue, 2020-06-30 at 00:06 +0100, Alexandre Neto wrote:
> Transifex Webtranslation page for QGIS is on 
> https://www.transifex.com/qgis/
> 
> Hi,
> 
> On Mon, Jun 29, 2020 at 11:38 PM Nyall Dawson  > wrote:
>  
> > What about a predefined allow list of "high quality translations"?
> > And
> > we'd only default to using the local language IF it's part of this
> > predefined list...
> 
> That would be a nice idea if we can ensure that there are enough
> native speakers available for doing the reviews and confirm that a
> certain language is ok to go. It's a really hard job, and it's always
> on the move. But, yes, maybe an overall appreciation could be enough
> to get the stamp of quality.
>  
> On Mon, Jun 29, 2020 at 11:42 PM Luigi Pirelli 
> wrote:
> > As far as I know, the italian translation suffer the same problem,
> > not about quality, but about resources to give continuity to
> > translation work. Spanish community, instead, is more focused in
> > translations (different official languages) than in features or
> > bugfixing.
> 
> Please notice that my worries are not the lack of translation of many
> strings, that is kind of ok to me. The problem are the badly
> translated ones.
> 
> The move to transifex made the translations available to many more
> translators, and we got more strings translated, but... while the
> QtLinguist translations had in some cases the GUI as context,
> transifex doesn't. 
> 
> Besides, at least in Portuguese, some people are more worried in
> quantity than in quality. Unfortunately, Transifex don't make it easy
> to find all the translation done by a bad translator... at least that
> I know of.
> 
> Alex
> 
> > Nyall
> > ___
> > QGIS-Translators mailing list
> > qgis...@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/qgis-tr
> 
> ___
> QGIS-Translators mailing list
> qgis...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-tr

___
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-tr] Concerns about translations and QGIS overall credibility

[Werner Macho]

Hi!

While we've got a lot more languages and translations now I share your
concerns too.
After all (and you alreade mentioned it) it is all volunteer work.
There is still the option of reviews on transifex, but I am a bit
concerned that translations AND reviews would be too much for some
languages.
The idea of having english as default language and let the user decide
if he wants to switch to the native language (probably with a warning
that the translation is done by volunteers) is a good one, but what to
do with the people who do not (or only a little) speak english?

Having good translations is hard work.

regards
Werner

On Tue, 2020-06-30 at 00:06 +0100, Alexandre Neto wrote:
> Transifex Webtranslation page for QGIS is on 
> https://www.transifex.com/qgis/
> 
> Hi,
> 
> On Mon, Jun 29, 2020 at 11:38 PM Nyall Dawson  > wrote:
>  
> > What about a predefined allow list of "high quality translations"?
> > And
> > we'd only default to using the local language IF it's part of this
> > predefined list...
> 
> That would be a nice idea if we can ensure that there are enough
> native speakers available for doing the reviews and confirm that a
> certain language is ok to go. It's a really hard job, and it's always
> on the move. But, yes, maybe an overall appreciation could be enough
> to get the stamp of quality.
>  
> On Mon, Jun 29, 2020 at 11:42 PM Luigi Pirelli 
> wrote:
> > As far as I know, the italian translation suffer the same problem,
> > not about quality, but about resources to give continuity to
> > translation work. Spanish community, instead, is more focused in
> > translations (different official languages) than in features or
> > bugfixing.
> 
> Please notice that my worries are not the lack of translation of many
> strings, that is kind of ok to me. The problem are the badly
> translated ones.
> 
> The move to transifex made the translations available to many more
> translators, and we got more strings translated, but... while the
> QtLinguist translations had in some cases the GUI as context,
> transifex doesn't. 
> 
> Besides, at least in Portuguese, some people are more worried in
> quantity than in quality. Unfortunately, Transifex don't make it easy
> to find all the translation done by a bad translator... at least that
> I know of.
> 
> Alex
> 
> > Nyall
> > ___
> > QGIS-Translators mailing list
> > qgis...@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/qgis-tr
> 
> ___
> QGIS-Translators mailing list
> qgis...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-tr

___
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-tr] Concerns about translations and QGIS overall credibility

[Alexandre Neto]

Hi,

On Mon, Jun 29, 2020 at 11:38 PM Nyall Dawson 
wrote:


> What about a predefined allow list of "high quality translations"? And
> we'd only default to using the local language IF it's part of this
> predefined list...
>

That would be a nice idea if we can ensure that there are enough native
speakers available for doing the reviews and confirm that a certain
language is ok to go. It's a really hard job, and it's always on the move.
But, yes, maybe an overall appreciation could be enough to get the stamp of
quality.

On Mon, Jun 29, 2020 at 11:42 PM Luigi Pirelli  wrote:

> As far as I know, the italian translation suffer the same problem, not
> about quality, but about resources to give continuity to translation work.
> Spanish community, instead, is more focused in translations (different
> official languages) than in features or bugfixing.
>

Please notice that my worries are not the lack of translation of many
strings, that is kind of ok to me. The problem are the badly translated
ones.

The move to transifex made the translations available to many more
translators, and we got more strings translated, but... while the
QtLinguist translations had in some cases the GUI as context, transifex
doesn't.

Besides, at least in Portuguese, some people are more worried in quantity
than in quality. Unfortunately, Transifex don't make it easy to find all
the translation done by a bad translator... at least that I know of.

Alex


> Nyall
> ___
> QGIS-Translators mailing list
> qgis...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-tr
___
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] Concerns about translations and QGIS overall credibility

[Luigi Pirelli]

As far as I know, the italian translation suffer the same problem, not
about quality, but about resources to give continuity to translation work.
Spanish community, instead, is more focused in translations (different
official languages) than in features or bugfixing.

Luigi Pirelli

**
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Book: Mastering QGIS3 - 3rd Edition

* Hire a team: http://www.qcooperative.net
**


On Tue, 30 Jun 2020 at 00:20, Alexandre Neto  wrote:

> Hi,
>
> I have been looking into the Portuguese translations of the GUI and the
> Docs, and I got really scared. Many translations were done completely out
> of context, making it very hard to read or understand what was
> originally written in English, even if you are familiar with the
> terminology.
>
> I don't know how other languages are going, and if you face the same
> problems. In Portugal, we have a very small community. Because of that,
> translation efforts are not really coordinated or even reviewed in most
> cases.
>
> Now, the biggest problem is that I think this deeply affects QGIS
> credibility. When you install QGIS, it defaults to the machine's locale,
> and many users don't even know how to change it (seen it in several
> courses). This means that many people will only know the badly translated
> version of QGIS in their native language... and It looks bad.
>
> In training, people sometimes make fun of the translations. I always
> enforce the idea that the translation work is fully done by volunteers in
> their spare time, but I am afraid if for some people it just looks like the
> full application was done by volunteers and hobbyists.
>
> So, I wanted to know if more of you face the same issues. If so, would it
> be wiser to default the language always to English and let the user find
> out how to change to his language if he wants to?
>
> Thanks,
>
> Alexandre Neto
>
> PS: Sorry for the cross-posting
>
>
> ___
> 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-tr] Concerns about translations and QGIS overall credibility

[Nyall Dawson]

On Tue, 30 Jun 2020 at 08:20, Alexandre Neto  wrote:

> So, I wanted to know if more of you face the same issues. If so, would it be 
> wiser to default the language always to English and let the user find out how 
> to change to his language if he wants to?

What about a predefined allow list of "high quality translations"? And
we'd only default to using the local language IF it's part of this
predefined list...

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

[QGIS-Developer] Concerns about translations and QGIS overall credibility

[Alexandre Neto]

Hi,

I have been looking into the Portuguese translations of the GUI and the
Docs, and I got really scared. Many translations were done completely out
of context, making it very hard to read or understand what was
originally written in English, even if you are familiar with the
terminology.

I don't know how other languages are going, and if you face the same
problems. In Portugal, we have a very small community. Because of that,
translation efforts are not really coordinated or even reviewed in most
cases.

Now, the biggest problem is that I think this deeply affects QGIS
credibility. When you install QGIS, it defaults to the machine's locale,
and many users don't even know how to change it (seen it in several
courses). This means that many people will only know the badly translated
version of QGIS in their native language... and It looks bad.

In training, people sometimes make fun of the translations. I always
enforce the idea that the translation work is fully done by volunteers in
their spare time, but I am afraid if for some people it just looks like the
full application was done by volunteers and hobbyists.

So, I wanted to know if more of you face the same issues. If so, would it
be wiser to default the language always to English and let the user find
out how to change to his language if he wants to?

Thanks,

Alexandre Neto

PS: Sorry for the cross-posting
___
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] Plugin [2052] Qveg approval notification.

[noreply]

Plugin Qveg approval by zimbogisgeek.
The plugin version "[2052] Qveg 4.2" is now approved
Link: http://plugins.qgis.org/plugins/qveg/
___
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] Plugin [2074] Google Earth Engine Data Catalog approval notification.

[noreply]

Plugin Google Earth Engine Data Catalog approval by zimbogisgeek.
The plugin version "[2074] Google Earth Engine Data Catalog 0.2.1" is now 
approved
Link: http://plugins.qgis.org/plugins/qgis_gee_data_catalog/
___
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 testing workflow with QgsMultiRenderChecker (on Windows and Travis)

[Olivier Dalang]

Dear list,

I'm struggling a little bit with tests using QgsMultiRenderChecker.

1/ Running the tests *on Windows*, I get some small rendering differences
with fonts that make tests fail. I'm getting the warnings below, both with
the font installed in my system or not. It seems to load the font with a
different size (20.1429 instead of 20) and as normal instead of bold, which
would explain why the test fail. Any idea why this happens, and how to fix
it ?

..\src\core\qgsfontutils.cpp(311) :
(QgsFontUtils::getStandardTestFont) [1372ms] Inexact font match -
consider installing the QGIS Vera Sans font.
..\src\core\qgsfontutils.cpp(312) :
(QgsFontUtils::getStandardTestFont) [0ms] Requested: QGIS Vera
Sans,20,-1,5,75,0,0,0,0,0,Bold
..\src\core\qgsfontutils.cpp(314) :
(QgsFontUtils::getStandardTestFont) [2ms] Replaced:  QGIS Vera
Sans,20.1429,47,5,75,0,0,0,0

2/ The QgsLayoutChecker tests outputs some HTML view of the failing tests,
allowing for a nice comparison of expected vs rendered images. When I run
the tests locally, I can redirect the output to a report.html file, then
see it in the browser (rather hacky, as all the test output goes in the
file, so it's not at all a proper html file, but it works).
Is it possible to somehow retrieve these results *from Travis *runs ? That
would be very helpful to workaround 1/.

Thanks !!

Olivier
___
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] Catch qgis exit

[Jan Růžička]

Thank you very much. That works perfectly and I think that they will
usually use the X button.

Jan Růžička, Ph.D.
freelancer, researcher and volontaire
Geoinformatics
tel: +420 775 032 091
e-mail: jan.ruzicka@gmail.com 
http://github.com/ruz76/
http://gismentors.eu/
http://dolnilhota.info/


Le lun. 29 juin 2020 à 07:04, Nyall Dawson  a
écrit :

> On Mon, 29 Jun 2020 at 14:39, Jan Růžička 
> wrote:
> >
> > Thank you. As you wrote, the problem is that this works only for the
> Widged of the plugin. There is not a way to override the closeEvent()
> method of the main QGIS Window from the plugin, since the plugin has only
> an interface given by the QGIS.
> >
> > I have decided to use the workaround for now, so when the QGIS is closed
> it will start again. The solution is not so perfect, but at least it is a
> solution.
> >
> > Another way to do this is to rewrite C++ code. The code is not so
> complicated and I can rewrite it, but then I have to build QGIS for all
> police stations and keep it updated and it is not so simple for me.
>
> Not sure how to intercept the quit action cleanly, but you can
> intercept the "X" button click:
>
> class NoClose(QObject):
>
> def __init__(self, parent=None):
> super().__init__(parent)
>
> def ok_to_close(self):
> return False
>
> def eventFilter(self, object, event):
> if isinstance(event, QCloseEvent):
> if not self.ok_to_close():
> event.ignore()
> return True
>
> return super().eventFilter( object, event )
>
> no_close = NoClose()
> iface.mainWindow().installEventFilter(no_close)
>
>
>
>
> >
> > Thank you again
> >
> > Jan Růžička, Ph.D.
> > freelancer, researcher and volontaire
> > Geoinformatics
> > tel: +420 775 032 091
> > e-mail: jan.ruzicka@gmail.com
> > http://github.com/ruz76/
> > http://gismentors.eu/
> > http://dolnilhota.info/
> >
> >
> > Le ven. 26 juin 2020 à 09:09, Ujaval Gandhi 
> a écrit :
> >>
> >> The way to achieve this would be to override the closeEvent() method of
> the main QGIs Window. I don't know how to do that. But you can do that on
> your plugin widget - which will at least prevent that dialog to be closed
> if certain conditions are not met.
> >>
> >> def closeEvent(self, event):
> >>   if condition:
> >> event.accept()
> >>   else:
> >> event.ignore()
> >> Ujaval Gandhi
> >> Spatial Thoughts
> >> mobile: +91-8095684687
> >> email: uja...@spatialthoughts.com
> >>
> >> Subscribe to our newsletter http://bit.ly/spatialthoughts-newsletter
> >>
> >>
> >>
> >> On Fri, Jun 26, 2020 at 10:02 AM Jan Růžička 
> wrote:
> >>>
> >>> Thank you very much, the same is possible in the unload method of the
> plugin, but the question is how to stop QGIS to exit.
> >>> I need to inform the user that he did not enter the result of the
> search and keep QGIS open for the user to enter the result.
> >>>
> >>> The possible workaround may be, to run the QGIS again, when it quits,
> but I thought that there may be some better way.
> >>>
> >>> Jan Růžička, Ph.D.
> >>> freelancer, researcher and volontaire
> >>> Geoinformatics
> >>> tel: +420 775 032 091
> >>> e-mail: jan.ruzicka@gmail.com
> >>> http://github.com/ruz76/
> >>> http://gismentors.eu/
> >>> http://dolnilhota.info/
> >>>
> >>>
> >>> Le jeu. 25 juin 2020 à 17:25, Ujaval Gandhi <
> uja...@spatialthoughts.com> a écrit :
> 
>  I saw that there is a aboutToQuit signal emitted just before a
> QApplication exists. The following works from QGIS Python Console.
> 
>  def test():
>  with open('/tmp/test.txt', 'w') as f:
>  f.write('wrote while exiting')
> 
>  qApp.aboutToQuit.connect(test)
>  Ujaval Gandhi
>  Spatial Thoughts
>  mobile: +91-8095684687
>  email: uja...@spatialthoughts.com
> 
>  Subscribe to our newsletter http://bit.ly/spatialthoughts-newsletter
> 
> 
> 
>  On Thu, Jun 25, 2020 at 5:00 PM Jan Růžička <
> jan.ruzicka@gmail.com> wrote:
> >
> > Dear developers,
> >
> > I have developed a plugin for the Police of the Czech Republic for
> Search and Rescue operations. It works quite well, but one important
> feature is missing.
> >
> > After the search event is finished the user should enter the result
> of the search.
> >
> > I was not able to find a way to catch an event when the user closes
> the whole QGIS. I need similar functionality like when closing in the case
> of a dirty project (no all changes were saved).
> >
> > I have searched a lot and did not find any solution. I was able to
> catch the unload event of the plugin, but I did not find a way to keep QGIS
> opened.
> >
> > Any help appreciated
> > Jan Růžička, Ph.D.
> > freelancer, researcher and volontaire
> > Geoinformatics
> > tel: +420 775 032 091
> > e-mail: jan.ruzicka@gmail.com
> > http://github.com/ruz76/
> > 

Re: [QGIS-Developer] Add function group to functions_help JSON files

[Alexandre Neto]

Ok, thanks for the clarification.

A segunda, 29/06/2020, 03:03, Nyall Dawson 
escreveu:

> On Mon, 22 Jun 2020 at 20:08, Alexandre Neto 
> wrote:
> >
> > Hi,
> >
> > TL;DR;
> >
> > Would it be ok to add a group key in the function help JSON files?
> Something like this:
> >
> > {
> > "name": "array_agg",
> > "type": "function", "group": "Aggregates",
>
> Just a warning that some functions are part of multiple different
> groups, so the "group" value here would actually need to be a list.
>
> But otherwise +1
>
> 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