[Qgis-developer] GarminCustomMap-plugin version update to 1.0

[Blumentrath, Stefan]

Hi again

I just reversioned the GarminCustomMap plugin to 1.0, removed the experimental 
flag and uploaded the new version to the repository.
If somebody with approval rights would be so kind to approve...
It should now work properly with QGIS 2.0.
In case of issues: the plugin has a bugtracker 
(http://hub.qgis.org/projects/garmincustommap/issues)...

Cheers
Stefan

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Projection of ESPG/ESRI

[Andre Joost]

Am 27.11.2013 20:12, schrieb Alex Mandel:

On 11/27/2013 10:56 AM, Randal Hale wrote:

So this question was going to be epic and confusing - and I just figured
it out. I also Cross posted this to the developers list - so excuse the
duplication.

I have a user who sent me  data in Georgia West State Plane NAD83 Feet.
In QGIS this comes up as a custom projection so I decided to define it.
According to QGIS I ended up with two EPSG choices - EPSG 102667 and
EPSG 2240. So this lead to some back and forth on my part mostly because
I was working tired. I searched the EPSG database and there is no
102667. This led to some head banging on my part.

I searched http://spatialreference.org/ref/?search=Georgia+West+ and
102667 is defined as an ESRI projection. Except in QGIS it comes up as
EPSG. Can this be fixed - can it be referenced as ESRI as opposed to EPSG?



I think that's a minor semantics issue, it's common knowledge that EPSG
code's over 10,000 are not actually official EPSG. But I'm not sure that
the label is stored in the db. Will have to look into that. More a
request to the developers list than here. And then of course I wonder if
we'll get in trouble for using the term ESRI without a trademark note.
Technically yes those projections come from the ESRI definitions, but
I'd guess that someone outside ESRI actually converted them to proj strings.



We also have IGNF: projection definitions, so why not giving ESRI the 
appropriate reference? They did not invent them, just gave the number.
Referencing to EPSG for projections that they did not publish is not 
better either.


I guess it comes from GDAL or PROJ4 after all. They have tables called 
ESRI with the extra definitions.


Greetings,
André Joost
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Projection of ESPG/ESRI

[Randal Hale]

Awesome - OK - I didn't know project on the fly would assign a 
projection. I usually leave it off - All the data needs to be in one 
projection anyway.


I should have known about the EPSG thing - I was too wrapped up in the 
data. I think having it as something other than EPSG would be better and 
probably would help some - but you are right the name ESRI would most 
likely kick up a stink of some sort.


I appreciate it.

Randy

-
Randal Hale, GISP
North River Geographic Systems, Inc
http://www.northrivergeographic.com
423.653.3611 rjh...@northrivergeographic.com

twitter:rjhale
http://about.me/rjhale

On 11/27/2013 02:12 PM, Alex Mandel wrote:

On 11/27/2013 10:56 AM, Randal Hale wrote:

So this question was going to be epic and confusing - and I just figured
it out. I also Cross posted this to the developers list - so excuse the
duplication.

I have a user who sent me  data in Georgia West State Plane NAD83 Feet.
In QGIS this comes up as a custom projection so I decided to define it.
According to QGIS I ended up with two EPSG choices - EPSG 102667 and
EPSG 2240. So this lead to some back and forth on my part mostly because
I was working tired. I searched the EPSG database and there is no
102667. This led to some head banging on my part.

I searched http://spatialreference.org/ref/?search=Georgia+West+ and
102667 is defined as an ESRI projection. Except in QGIS it comes up as
EPSG. Can this be fixed - can it be referenced as ESRI as opposed to EPSG?


I think that's a minor semantics issue, it's common knowledge that EPSG
code's over 10,000 are not actually official EPSG. But I'm not sure that
the label is stored in the db. Will have to look into that. More a
request to the developers list than here. And then of course I wonder if
we'll get in trouble for using the term ESRI without a trademark note.
Technically yes those projections come from the ESRI definitions, but
I'd guess that someone outside ESRI actually converted them to proj strings.


Also - it seems when I pull data without a projection it inherits EPSG
4326 (WGS84) - is there a way in QGIS to pull in data with no
projection? In some cases we have to figure it out - so it coming in as
undefined is more helpful than inheriting an incorrect projection.


Just leave Projection on the fly off (the default). That will give you
the behavior of a naive coordinate system and a chance to figure out and
define the correct coordinate system.


Anyway - Happy Thanksgiving for those of you who fall in that geographic
social area.

Randy


Thanks,
Alex


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Projection of ESPG/ESRI

[Alex Mandel]

On 11/27/2013 10:56 AM, Randal Hale wrote:
> So this question was going to be epic and confusing - and I just figured
> it out. I also Cross posted this to the developers list - so excuse the
> duplication.
> 
> I have a user who sent me  data in Georgia West State Plane NAD83 Feet.
> In QGIS this comes up as a custom projection so I decided to define it.
> According to QGIS I ended up with two EPSG choices - EPSG 102667 and
> EPSG 2240. So this lead to some back and forth on my part mostly because
> I was working tired. I searched the EPSG database and there is no
> 102667. This led to some head banging on my part.
> 
> I searched http://spatialreference.org/ref/?search=Georgia+West+ and
> 102667 is defined as an ESRI projection. Except in QGIS it comes up as
> EPSG. Can this be fixed - can it be referenced as ESRI as opposed to EPSG?
> 

I think that's a minor semantics issue, it's common knowledge that EPSG
code's over 10,000 are not actually official EPSG. But I'm not sure that
the label is stored in the db. Will have to look into that. More a
request to the developers list than here. And then of course I wonder if
we'll get in trouble for using the term ESRI without a trademark note.
Technically yes those projections come from the ESRI definitions, but
I'd guess that someone outside ESRI actually converted them to proj strings.

> Also - it seems when I pull data without a projection it inherits EPSG
> 4326 (WGS84) - is there a way in QGIS to pull in data with no
> projection? In some cases we have to figure it out - so it coming in as
> undefined is more helpful than inheriting an incorrect projection.
> 

Just leave Projection on the fly off (the default). That will give you
the behavior of a naive coordinate system and a chance to figure out and
define the correct coordinate system.

> Anyway - Happy Thanksgiving for those of you who fall in that geographic
> social area.
> 
> Randy
> 

Thanks,
Alex
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Projection of ESPG/ESRI

[Randal Hale]

So this question was going to be epic and confusing - and I just figured 
it out. I also Cross posted this to the developers list - so excuse the 
duplication.


I have a user who sent me  data in Georgia West State Plane NAD83 Feet. 
In QGIS this comes up as a custom projection so I decided to define it. 
According to QGIS I ended up with two EPSG choices - EPSG 102667 and 
EPSG 2240. So this lead to some back and forth on my part mostly because 
I was working tired. I searched the EPSG database and there is no 
102667. This led to some head banging on my part.


I searched http://spatialreference.org/ref/?search=Georgia+West+ and 
102667 is defined as an ESRI projection. Except in QGIS it comes up as 
EPSG. Can this be fixed - can it be referenced as ESRI as opposed to EPSG?


Also - it seems when I pull data without a projection it inherits EPSG 
4326 (WGS84) - is there a way in QGIS to pull in data with no 
projection? In some cases we have to figure it out - so it coming in as 
undefined is more helpful than inheriting an incorrect projection.


Anyway - Happy Thanksgiving for those of you who fall in that geographic 
social area.


Randy

--
-
Randal Hale, GISP
North River Geographic Systems, Inc
http://www.northrivergeographic.com
423.653.3611 rjh...@northrivergeographic.com

twitter:rjhale
http://about.me/rjhale

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] customization option issues

[matteo]

Hi guys,
trying to customize the qgis toolbar and menu I found something weird 
(maybe a bug)


 * saving the customization, you have to add manually the .ini suffix
   to the file, otherwise you are not able to load it
 * there are some problem with the customization of the menu: e.g.
   after removing "geoprocessing" and "geometry" from the Vector menu,
   when qg restarts they are are still enabled. Same issue for the
   others menu

Cheers

Matteo


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Please approve GarminCustomMap-plugin version 0.100

[Blumentrath, Stefan]

Hi again

And Thanks for approving and the hint with the version number.

I was not aware that the loogics change from 0.99 to 0.100.
I shall keep that in mind for the future...

I thought I make it 1.0 (and non experimental) when people out there confirm 
the plugin works properly on their (probably different systems)...

Cheers
Stefan

-Original Message-
From: Richard Duivenvoorde [mailto:rdmaili...@duif.net] 
Sent: 26. november 2013 22:58
To: Blumentrath, Stefan; qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Please approve GarminCustomMap-plugin version 
0.100

On 26-11-13 22:16, Blumentrath, Stefan wrote:
> Hi
> 
> It would be great if someone with approval rights could approve the latest 
> version (0.100) of the GarminCustomMap plugin.
> The earlier version did not geo-reference the jpgs properly in the kml/kmz, 
> in other words: output from version 0.99 will be useless...

Hi Stefan,

just did. BUT first could not find it, while it is sorted on version number in 
the list.

it is because you went from 0.99 to 0.100 == 0.1 So in normal versioning scheme 
you DOWNgraded your plugin.
So also for the pluginmanager I think your latest version is 0.99

Please version this version as either 0.991 or 0.99.1 or so if you really want 
to stay away from the magic one :-)

Regards,

Richard Duivenvoorde

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Context help is evil and old

[Paolo Cavallini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 27/11/2013 13:07, Alexander Bruy ha scritto:
> Hi Richard,
> 
> this topic was discussed several times, last discussion was 
> initiated by me about month ago [0].
> 
> I completely agree with you, we should drop context help and move
> all texts into docs. This help us to keep context help updated and
> translated.
> 
> +1 from me

agreed: let's reduce duplication.
in this case, I would distribute the html manual along with the
application, and point the context help to the relevant page.
before dropping the context help, please documenters check that all
the content is also present in the manual (e.g. I have found the
description of Heatmap plugin quite good in the CH, unsure if it's
also on the manual).
Thanks.
- -- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlKV4z8ACgkQ/NedwLUzIr6MDQCgq3rnK3M0noa13Xn1azatGlR8
QiUAnRk8eyC0NhuQvab+KlcwPKdtXDnS
=iezY
-END PGP SIGNATURE-
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Context help is evil and old

[Alexander Bruy]

Hi Richard,

this topic was discussed several times, last discussion was
initiated by me about month ago [0].

I completely agree with you, we should drop context help and
move all texts into docs. This help us to keep context help
updated and translated.

+1 from me

[0] 
http://osgeo-org.1560.x6.nabble.com/Qgis-community-team-QGIS-context-help-td5085399.html

2013/11/27 Richard Duivenvoorde :
> Hi,
>
> while the idea of context help buttons in dialogs is great...
>
> In practice that help is either not available, or outdated or not
> translated or (differently) duplicated into the Documentation
> (and as a tranlator it is pretty boring to translate all the context
> help texts).
>
> What about unifying all help in the Manual (website). With Sphinx (our
> docs are generated with it) it is pretty easy to point to a specific
> paragraph in the manual ( right click on the paragraph sign next to the
> heading ). Eg the section about loading shapfiles:
>
> http://www.qgis.org/en/docs/user_manual/working_with_vector/supported_data.html#loading-a-shapefile
>
> We could:
>
> 1) either just put a link into the context help so a connected user can
> jump to the docs website
>
> 2) or we could load that page in the QGIS help dialog (in a webkit widget)
>
> 3) or (??) we could try to package the docs into the QGIS install and
> load the local file inot the QGIS help dialog.
>
> Only 'problem' I see is that we maybe have to write some more
> specialized or more general paragraphs in the manual which are suited
> for the context help. I'm thinking about for example the description of
> all the functions in the field calculator etc. Or in case of the 'Open
> Vector Layer Dialog' about a more general paragraph about the loading of
> vector data via OGR.
>
> Another example of very different results for the same topic:
>
> The context help for delimited text context help is VERY verbose and
> helpfull:
>
> https://github.com/qgis/QGIS/blob/master/resources/context_help/QgsDelimitedTextSourceSelect
>
> While compared with the docs, these are rather thin:
>
> http://www.qgis.org/en/docs/user_manual/introduction/general_tools.html?highlight=delimited#add-delimited-text-layer
>
> So my proposal: let's get rid of help TEXT in the context help. Put all
> text (and energy) in DOCS and link to them or show them.
>
> Regards,
>
> Richard Duivenvoorde
>
>
>
>
>
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer



-- 
Alexander Bruy
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] PR1007 bump minimum to 4.7: objections?

[Richard Duivenvoorde]

On 27-11-13 11:43, Sandro Santilli wrote:
> May I ask why this discussion is happening here rather than 
> on the pull request page ? I'd feel pretty lonely if I was
> the contributor of it... :(

Because I thought this was the appropriate audience. I can myself start
 discussion on the PR page, but then the most important devs are not
aware of it.

Also because I thought this was a typical/principal question.

For me this discussion was helpfull. I will point the PR-owner to this
thread (actually I already commented there that I would ask the lists)

Regards,

Richard Duivenvoorde
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] PR1007 bump minimum to 4.7: objections?

[Nyall Dawson]

Ok - to add some context to this discussion -- I originally requested
that we bump the dependency to 4.6 to get access to
QGraphicsItem::rotation() and QGraphicsItem::setRotation(). I need
these to fix composer item rotation. It's a bit of a code cleanup, but
mostly a feature win in that using those methods I can add rotation to
all types of composer items. It's 98% of the way there in these
commits:
https://github.com/nyalldawson/QGIS/commit/bd92774ea7ea5ed50a4fad9c83f45540125d61e0
https://github.com/nyalldawson/QGIS/commit/f05dceb4bd63ca786aa36c0a60a8302567854889

Pull request 1007 is basically a prerequisite to finishing this work.
If there's no chance of getting the minimum to 4.6 then I'll have to
abandon this branch. That's why I'm hoping to get 1007 pulled before
spending too much more time on a feature which currently is impossible
to merge to master.

Early in this thread there was overwhelming support for setting the
minimum to 4.8 - that's why request 1006 was opened. 1006 can probably
be closed now since 4.8 looks unlikely.

Nyall


On 27 November 2013 21:43, Sandro Santilli  wrote:
> May I ask why this discussion is happening here rather than
> on the pull request page ? I'd feel pretty lonely if I was
> the contributor of it... :(
>
> --strk;
>
> On Wed, Nov 27, 2013 at 11:26:05AM +0100, Jürgen E. Fischer wrote:
>> Hi Richard,
>>
>> On Wed, 27. Nov 2013 at 10:25:36 +0100, Richard Duivenvoorde wrote:
>> > > I don't see a point in this.  The pull request will just break the lucid
>> > > builds without adding anything new (or cleaning out any old code that
>> > > requires Qt <4.7).
>>
>> > Ok. Clear. Then we should close the two pull requests with the message: we
>> > want to provide lucid builds untill  so before that time we will not
>> > upgrade Qt...
>>
>> Apparently not so clear.  Lucid is not the point.  It that it's just breaking
>> something w/o achieving anything else.  And that's essentially the only thing
>> it does.
>>
>> QGIS currently works with earlier versions.  That (tiny) change could be part
>> of a larger PR that removes all the old ifdefed code, that will become 
>> useless,
>> once QGIS refuses to be compiled on Qt <4.7 anyway.  Or when something else 
>> is
>> added that requires Qt 4.7 (and which needs some effort to to maintain for Qt
>> <4.7).
>>
>>
>> Jürgen
>>
>> --
>> Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-31
>> Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
>> Software Engineer D-26506 Norden   http://www.norbit.de
>> QGIS PSC member (RM)   IRC: jef on FreeNode
>>
>> --
>> norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
>> Rheinstrasse 13, 26506 Norden
>> GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502
>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> --
>
>  ()  ASCII ribbon campaign- against html e-mail
>  /\  http://www.asciiribbon.org   - against proprietary attachments
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Context help is evil and old

[Jonathan Moules]

Hi Richard,
For reference, I opened a ticket on this a couple of months ago -
http://hub.qgis.org/issues/8699 - and had similar findings to yourself
Cheers,
Jonathan


On 27 November 2013 08:31, Richard Duivenvoorde  wrote:

> Hi,
>
> while the idea of context help buttons in dialogs is great...
>
> In practice that help is either not available, or outdated or not
> translated or (differently) duplicated into the Documentation
> (and as a tranlator it is pretty boring to translate all the context
> help texts).
>
> What about unifying all help in the Manual (website). With Sphinx (our
> docs are generated with it) it is pretty easy to point to a specific
> paragraph in the manual ( right click on the paragraph sign next to the
> heading ). Eg the section about loading shapfiles:
>
>
> http://www.qgis.org/en/docs/user_manual/working_with_vector/supported_data.html#loading-a-shapefile
>
> We could:
>
> 1) either just put a link into the context help so a connected user can
> jump to the docs website
>
> 2) or we could load that page in the QGIS help dialog (in a webkit widget)
>
> 3) or (??) we could try to package the docs into the QGIS install and
> load the local file inot the QGIS help dialog.
>
> Only 'problem' I see is that we maybe have to write some more
> specialized or more general paragraphs in the manual which are suited
> for the context help. I'm thinking about for example the description of
> all the functions in the field calculator etc. Or in case of the 'Open
> Vector Layer Dialog' about a more general paragraph about the loading of
> vector data via OGR.
>
> Another example of very different results for the same topic:
>
> The context help for delimited text context help is VERY verbose and
> helpfull:
>
>
> https://github.com/qgis/QGIS/blob/master/resources/context_help/QgsDelimitedTextSourceSelect
>
> While compared with the docs, these are rather thin:
>
>
> http://www.qgis.org/en/docs/user_manual/introduction/general_tools.html?highlight=delimited#add-delimited-text-layer
>
> So my proposal: let's get rid of help TEXT in the context help. Put all
> text (and energy) in DOCS and link to them or show them.
>
> Regards,
>
> Richard Duivenvoorde
>
>
>
>
>
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>

-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] PR1007 bump minimum to 4.7: objections?

[Sandro Santilli]

May I ask why this discussion is happening here rather than 
on the pull request page ? I'd feel pretty lonely if I was
the contributor of it... :(

--strk;

On Wed, Nov 27, 2013 at 11:26:05AM +0100, Jürgen E. Fischer wrote:
> Hi Richard,
> 
> On Wed, 27. Nov 2013 at 10:25:36 +0100, Richard Duivenvoorde wrote:
> > > I don't see a point in this.  The pull request will just break the lucid
> > > builds without adding anything new (or cleaning out any old code that
> > > requires Qt <4.7).
>  
> > Ok. Clear. Then we should close the two pull requests with the message: we
> > want to provide lucid builds untill  so before that time we will not
> > upgrade Qt...
> 
> Apparently not so clear.  Lucid is not the point.  It that it's just breaking
> something w/o achieving anything else.  And that's essentially the only thing
> it does.
> 
> QGIS currently works with earlier versions.  That (tiny) change could be part
> of a larger PR that removes all the old ifdefed code, that will become 
> useless,
> once QGIS refuses to be compiled on Qt <4.7 anyway.  Or when something else is
> added that requires Qt 4.7 (and which needs some effort to to maintain for Qt
> <4.7).
> 
> 
> Jürgen
> 
> -- 
> Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-31
> Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
> Software Engineer D-26506 Norden   http://www.norbit.de
> QGIS PSC member (RM)   IRC: jef on FreeNode   
>   
> 
> -- 
> norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
> Rheinstrasse 13, 26506 Norden
> GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 

 ()  ASCII ribbon campaign- against html e-mail
 /\  http://www.asciiribbon.org   - against proprietary attachments
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] PR1007 bump minimum to 4.7: objections?

[Jürgen E . Fischer]

Hi Richard,

On Wed, 27. Nov 2013 at 10:25:36 +0100, Richard Duivenvoorde wrote:
> > I don't see a point in this.  The pull request will just break the lucid
> > builds without adding anything new (or cleaning out any old code that
> > requires Qt <4.7).
 
> Ok. Clear. Then we should close the two pull requests with the message: we
> want to provide lucid builds untill  so before that time we will not
> upgrade Qt...

Apparently not so clear.  Lucid is not the point.  It that it's just breaking
something w/o achieving anything else.  And that's essentially the only thing
it does.

QGIS currently works with earlier versions.  That (tiny) change could be part
of a larger PR that removes all the old ifdefed code, that will become useless,
once QGIS refuses to be compiled on Qt <4.7 anyway.  Or when something else is
added that requires Qt 4.7 (and which needs some effort to to maintain for Qt
<4.7).


Jürgen

-- 
Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-31
Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
Software Engineer D-26506 Norden   http://www.norbit.de
QGIS PSC member (RM)   IRC: jef on FreeNode 


-- 
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] PR1007 bump minimum to 4.7: objections?

[Werner Macho]

Hi!

As I already wrote in some of my former emails and Richard pointed it
out in his email

DESKTOP support for lucid is already ceased
SERVER support is still valid until mid of 2015

https://wiki.ubuntu.com/LTS

As our packages are not in the "official repository" of these projects
anyway I doubt we MUST take care of that.
Personally I think there is only a minority still using Lucid out there ..

If there is a _good_ reason for pushing QT MIN to 4.8 I would drop
lucid and do it.

kind regards
Werner


On Wed, Nov 27, 2013 at 11:25 AM, Richard Duivenvoorde
 wrote:
> On 27-11-13 09:34, Jürgen E. Fischer wrote:
>> Hi Richard,
>>
>> On Wed, 27. Nov 2013 at 08:17:47 +0100, Richard Duivenvoorde wrote:
>>> to be able to clean up the Pull Request list, I ask people if anybody
>>> objects to bumping minimum Qt to 4.7
>>
>> I don't see a point in this.  The pull request will just break the lucid 
>> builds
>> without adding anything new (or cleaning out any old code that requires Qt
>> <4.7).
>
> Ok. Clear. Then we should close the two pull requests with the message:
> we want to provide lucid builds untill  so before that time we will
> not upgrade Qt...
>
> BUT: I read that Canonical does not support lucid on the desktop
> anymore, but given that we also have QGIS-server, we cannot move until
> april 2015 :-(
>
> http://en.wikipedia.org/wiki/List_of_Ubuntu_releases#Ubuntu_10.04_LTS_.28Lucid_Lynx.29
>
> Same counts for the old Red Hat/RHEL versions.
>
> If companies like redhat and canonical stop upgrading applications
> (being desktop or server), should we as a project keep supporting QGIS
> with our testing/master version?
>
> People who use RHEL and Canonical LTS are used to older versions of
> applications, so in QGIS case, could stay with QGIS2.0?
>
> Sorry for stirring this up again. As a project should take a position on
> this, I think?
>
> I agree that this specific Pull Request does not clean up code. But we
> can also ask the PR-owner to either do that, or see this PR as the first
> step for this.
>
> Regards,
>
> Richard Duivenvoorde
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] PR1007 bump minimum to 4.7: objections?

[Richard Duivenvoorde]

On 27-11-13 09:34, Jürgen E. Fischer wrote:
> Hi Richard,
> 
> On Wed, 27. Nov 2013 at 08:17:47 +0100, Richard Duivenvoorde wrote:
>> to be able to clean up the Pull Request list, I ask people if anybody
>> objects to bumping minimum Qt to 4.7
> 
> I don't see a point in this.  The pull request will just break the lucid 
> builds
> without adding anything new (or cleaning out any old code that requires Qt
> <4.7).

Ok. Clear. Then we should close the two pull requests with the message:
we want to provide lucid builds untill  so before that time we will
not upgrade Qt...

BUT: I read that Canonical does not support lucid on the desktop
anymore, but given that we also have QGIS-server, we cannot move until
april 2015 :-(

http://en.wikipedia.org/wiki/List_of_Ubuntu_releases#Ubuntu_10.04_LTS_.28Lucid_Lynx.29

Same counts for the old Red Hat/RHEL versions.

If companies like redhat and canonical stop upgrading applications
(being desktop or server), should we as a project keep supporting QGIS
with our testing/master version?

People who use RHEL and Canonical LTS are used to older versions of
applications, so in QGIS case, could stay with QGIS2.0?

Sorry for stirring this up again. As a project should take a position on
this, I think?

I agree that this specific Pull Request does not clean up code. But we
can also ask the PR-owner to either do that, or see this PR as the first
step for this.

Regards,

Richard Duivenvoorde
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] PR1007 bump minimum to 4.7: objections?

[Jürgen E . Fischer]

Hi Richard,

On Wed, 27. Nov 2013 at 08:17:47 +0100, Richard Duivenvoorde wrote:
> to be able to clean up the Pull Request list, I ask people if anybody
> objects to bumping minimum Qt to 4.7

I don't see a point in this.  The pull request will just break the lucid builds
without adding anything new (or cleaning out any old code that requires Qt
<4.7).


Jürgen

-- 
Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-31
Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
Software Engineer D-26506 Norden   http://www.norbit.de
QGIS PSC member (RM)   IRC: jef on FreeNode 


-- 
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Context help is evil and old

[Richard Duivenvoorde]

Hi,

while the idea of context help buttons in dialogs is great...

In practice that help is either not available, or outdated or not
translated or (differently) duplicated into the Documentation
(and as a tranlator it is pretty boring to translate all the context
help texts).

What about unifying all help in the Manual (website). With Sphinx (our
docs are generated with it) it is pretty easy to point to a specific
paragraph in the manual ( right click on the paragraph sign next to the
heading ). Eg the section about loading shapfiles:

http://www.qgis.org/en/docs/user_manual/working_with_vector/supported_data.html#loading-a-shapefile

We could:

1) either just put a link into the context help so a connected user can
jump to the docs website

2) or we could load that page in the QGIS help dialog (in a webkit widget)

3) or (??) we could try to package the docs into the QGIS install and
load the local file inot the QGIS help dialog.

Only 'problem' I see is that we maybe have to write some more
specialized or more general paragraphs in the manual which are suited
for the context help. I'm thinking about for example the description of
all the functions in the field calculator etc. Or in case of the 'Open
Vector Layer Dialog' about a more general paragraph about the loading of
vector data via OGR.

Another example of very different results for the same topic:

The context help for delimited text context help is VERY verbose and
helpfull:

https://github.com/qgis/QGIS/blob/master/resources/context_help/QgsDelimitedTextSourceSelect

While compared with the docs, these are rather thin:

http://www.qgis.org/en/docs/user_manual/introduction/general_tools.html?highlight=delimited#add-delimited-text-layer

So my proposal: let's get rid of help TEXT in the context help. Put all
text (and energy) in DOCS and link to them or show them.

Regards,

Richard Duivenvoorde







___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer