On 06-11-14 10:41, Matthias Kuhn wrote:
On 06.11.2014 10:33, Matthias Kuhn wrote:
could the migration have an impact on plugins?
Yes, some classes are no longer supported but the delta is small
The biggest problem will probably be old-style signal/slot connections.
Maybe we should encourage
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
which branch do I have to checkout to test a qt5 compile run?
regards
Werner
On 11/07/2014 09:13 AM, Richard Duivenvoorde wrote:
On 06-11-14 10:41, Matthias Kuhn wrote:
On 06.11.2014 10:33, Matthias Kuhn wrote:
could the migration have an impact
Hi Werner
https://github.com/m-kuhn/QGIS/tree/final-2_4_0-qt5
You may need to revert
9c6f1698fcb3
Make sure that dependencies are also compiled and linked against Qt5
(QWT/QWTPolar being the most prominent ones).
Start in an empty build directory
run `cmake -DENABLE_QT5=TRUE
hmm
obviously Qt5.3 is minimum for compiling .. because it is searching
for a qtpositioning here and as I only have Qt5.1.1 available here I
am out of testing it :)
waiting for the distribution update *gg*
thanks for the info anyway ..
regards
Werner
On Fri, Nov 7, 2014 at 9:20 AM, Matthias Kuhn
Hello,
I Submitted the new version of VTerrain inserting github as a repository and
tracker.
However, I did a stupid thing: I accidentally deleted the entire project
VTerrain in qgis repository (while I wanted to delete only the last version)
.
Then I re-created by inserting the latest
You're right Jonathan,
If I choose the option « Only search in the metadata table SRID is correctly
displayed.
But this is a difference between releases.
Thanks
De : Jonathan Moules [mailto:j.mou...@hrwallingford.com]
Envoyé : jeudi 6 novembre 2014 18:08
À : PIERRE Sylvain;
I just created a pull request for Qt5.
There is no QtPositioning in there, so you may try again if you like so :)
Anybody is kindly invited to test, review and comment.
Thank you
On 11/07/2014 09:37 AM, Werner Macho wrote:
hmm
obviously Qt5.3 is minimum for compiling .. because it is
Dear list,
i'm trying lizmap web client and can't get how the print tool
is to be configured.
I'm using ubuntu server 12.04 with qgis-server (2.6.0.);
for the QGIS project i'm using QGIS 2.0.6.
The Lizmap (2.10.0) demo works, also the print tool works for the demo
project,
so i think i'm
hm - I can't tell you exactly what the problem is.
BUT: you cannot mix versions. If your server runs on QGIS 2.6, your
client where you prepare the project also needs to be of the same
version 2.6. Those different versions are not necessarily compatible.
It will open all sorts of problems if
Il 07/11/2014 11.54, Andreas Neumann ha scritto:
hm - I can't tell you exactly what the problem is.
BUT: you cannot mix versions. If your server runs on QGIS 2.6, your
client where you prepare the project also needs to be of the same
version 2.6. Those different versions are not necessarily
Hi Roy,
The documentation is not fully in english but the documentation exists
in French.
The page about configuring print is here :
http://docs.3liz.com/fr/publisher_guide/advanced_lizmap_config.html#configurer-l-impression
Do you have activated Print capabilities for the map in lizmap
Hi all,
I'm seeking feedback about the best way to move forward with QGIS' map
composer. I'm currently running up against some large issues with the
current design and API of composer which are holding back important
features and fixes. Some of these issues include:
- there's too much composer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
HI all.
I'm getting an error:
=
Errore durante l'esecuzione di codice Python:
Traceback (most recent call last):
File
/home/paolo/.qgis2/python/plugins/MetaSearch/dialogs/maindialog.py,
line 471, in search
I'm wondering whether it has to do with a composer legend item crasher that
Martin fixed days ago.
Are users sharing the project files that make qgis crash?
On 7 Nov 2014 20:53, Giovanni Manghi giovanni.man...@faunalia.pt wrote:
Hi all,
we are getting quite a lot of feedback (in the tracker,
Hi Giovanni,
This is still too vague. We need to narrow down the issues.
How about the plugins? Still crashes with no plugins?
What data sources? Is MTR on or not?
Please ask the reporter to provide more details and ask them to disable
all plugins and retry.
Andreas
On 07.11.2014 14:53,
Ddear Renè-Luc,
thanks for you answer
Il 07/11/2014 12.30, René-Luc Dhont ha scritto:
Hi Roy,
The documentation is not fully in english but the documentation exists
in French.
The page about configuring print is here :
Hi all,
I noticed that the help files of SAGA are not aligned with the algorithms.
Shape buffer (fixed distance) and shape buffer (attributes distance)
have the same help that is not aligned with the parameter window.
Should I open a ticket?
Cheers
Matteo
Hi Roy,
I take a look at the commit list in lizmap-web-client release 2.10 and
we fixed this bug after the release.
https://github.com/3liz/lizmap-web-client/commits/release_2_10
We need to publish a bugfix release just for QGIS 2.6. The issue is due
to the new way to define overview in the
HI all,
working with the Master (but I think same behavior on 2.6) I cannot
see the option save models as python script anymore..
Am I missing something?
Cheers
Matteo
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
Hi Nyall,
as I already told you privately, I agree with the second approach: remove
the current Composer and guarantee transparent auto-upgrade of existing
layouts in projects.
The improvements to the composer worth the effort, and the consequent
visual impact for users. The important thing is to
Hi Nyall,
I also think that option 2 would work best. Option one would be very
confusing (I remember the days when we had two labeling versions, 2
symbology versions, etc. - awful!).
Thanks,
Andreas
On 07.11.2014 16:16, G. Allegri wrote:
Hi Nyall,
as I already told you privately, I agree
Dear Renè-Luc,
thank you very much for your help,
i can confirm you that with the first test the Print Tool is working
on your release_2_10,
best regards,
Roy.
Il 07/11/2014 16.02, René-Luc Dhont ha scritto:
Hi Roy,
I take a look at the commit list in lizmap-web-client release 2.10 and
we
Can you verify on a recent master build?
Martin has fixed something that could be related.
https://github.com/qgis/QGIS/commit/b1b0db6b7bdef10dcf6189db0b60d0176629bb99
Matthias
On 07.11.2014 15:16, Andreas Neumann wrote:
Hi Giovanni,
This is still too vague. We need to narrow down the
Hi,
I'm using QGIS 2.6.0 on Win 7 x64 - installed via OSGEO4w
Is there a way to store your field calculator expression to always
process and update that specific field, should geometry be edited or
created for that Layer?
Let's say I want to create a blank POINT shape file, with a text
Hi Zoltan,
Since QGIS 2.6 this possibility exists. It is called Virtual Field.
You must not create the attribute when creating the shapefile. Just open
the field calculator, create a new field in there and check the virtual
field checkbox.
Regards,
Matthias
On 07.11.2014 16:54, Zoltan Szecsei
Hi Matthias,
Thanks for the quick answer.
The virtual field acts just like I want it to, except that it does not
permanently store the column in the attribute table.
I tried getting clever by then adding a second 'Field Calculation' to
update the existing 'Sheet' field from the virtual field,
Hi,
What you probably ask for are database triggers combined with storage.
This is not what virtual fields are for. If they were stored - they
wouldn't be called virtual ;-)
You can do that f.e. with Postgis. With shapefiles not. However, if you
share the project with the other PC, the
Hi Andreas,
I'll fiddle with the Postgis idea - thanks.
The orange part below:
I closed the shapefile, deleted from legend and re-opened it - but could
not see my virtual field, nor the expression I used to create it.
Have I missed a trick somewhere?
Regards,
Z
On 2014/11/07 18:25, Andreas
On 07.11.2014 17:25, Andreas Neumann wrote:
Hi,
What you probably ask for are database triggers combined with storage.
This is not what virtual fields are for. If they were stored - they
wouldn't be called virtual ;-)
we could still add materialized virtual fields :-)
You can do that f.e.
Hi Zoltan,
If you remove and re-add the shapefile you will of course loose the
virtual fields, as they are stored with the project and not with the data.
However, if you save a layer definition file along with the shapefile
and re-add that, they are preserved. So you can just store the layer
On Fri, Nov 7, 2014 at 9:11 PM, Mathieu Pellerin nirvn.a...@gmail.com wrote:
I'm wondering whether it has to do with a composer legend item crasher that
Martin fixed days ago.
On 7 Nov 2014 20:53, Giovanni Manghi giovanni.man...@faunalia.pt wrote:
http://hub.qgis.org/issues/11593
Indeed it
On 2014/11/07 19:19, Zoltan Szecsei wrote:
Thanks for the pointer to 'Save Layer Definition file' - I've never
noticed that, so I'll play with that for a bit.
On 2014/11/07 18:59, Andreas Neumann wrote:
However, if you save a layer definition file along with the shapefile
and re-add that,
On Tue, Nov 4, 2014 at 1:53 AM, Luigi Pirelli lui...@gmail.com wrote:
Hi martin
I almost agree, but qgis is not only a lib but kind of framework. It's
use is different tespect the use i van do with qt or gdal.
Not always I've the code available to investigate... but I generally
have
Hi,
I don't get the point in keeping the old classes if we upgrade the
composers to layouts at opening ? Doesn't migration happen at XML level ?
Maybe while thinking about reworking the composer, we could think about a
new feature : real templates (aka masters in Indesign).
All elements added
IMO, this is serious enough to package a 2.6.1 release speedily. There are
enough ppl out there that don't backup their documents on a regular basis
for this bug to be hugely problematic.
On 8 Nov 2014 00:49, Martin Dobias wonder...@gmail.com wrote:
On Fri, Nov 7, 2014 at 9:11 PM, Mathieu
On 08/11/2014 6:11 am, Olivier Dalang olivier.dal...@gmail.com wrote:
Hi,
I don't get the point in keeping the old classes if we upgrade the
composers to layouts at opening ? Doesn't migration happen at XML level ?
It would allow standalone scripts which utilise compositions, or scripts
which
Nyall,
Please, let's not go down the road of two options to do the same thing (ala
double symbology double labelling engine era of qgis 1.x)
Nor can we leave users' previously saved composers broken.
So #2 seems to be the wining option.
A fundamental change like that would go very well with a
Hi Hugo
On Tue, Nov 4, 2014 at 8:36 PM, Hugo Mercier hugo.merc...@oslandia.com wrote:
* About indexes on virtual tables, contrary to what I wrote previously,
the xBestIndex() method of virtual tables should be enough to orient the
planner, an estimated cost and estimated number of rows can be
Hi all,
I'm just wondering - given a few large changes coming up, including:
- qt5 support, possibly breaking plugins
- potential composer redesign, breaking api
- geometry rework, where an api break would result in a better
foundation moving forward
... is it worth exploring the idea of making
Personally I think we should still do 2.8, LTR it, and then we can do 3.0
for the next release.
Breaking the API again without a LTR in place makes me nervous as the 2.0
API really wasn't that long ago.
- Nathan
On Sat Nov 08 2014 at 4:11:34 PM Nyall Dawson nyall.daw...@gmail.com
wrote:
Hi
On 08/11/2014 6:01 pm, Nathan Woodrow madman...@gmail.com wrote:
Personally I think we should still do 2.8, LTR it, and then we can do 3.0
for the next release.
Couldn't we branch 2.6 off to become a LTR?
Nyall
___
Qgis-developer mailing list
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 08/11/2014 01:32, Mathieu Pellerin ha scritto:
IMO, this is serious enough to package a 2.6.1 release speedily.
There are enough ppl out there that don't backup their documents on
a regular basis for this bug to be hugely problematic.
seems
42 matches
Mail list logo
