Thanks maris.
Are grass dev aware of the problem? Could we then display grass in English when
on windows, for these languages?
It seems important.
All the best.
Maris Nartiss maris@gmail.com ha scritto:
Hello Paolo,
I haven't seen how QGIS GRASS plug in is built, still my 0.02 from
GRASS
Hi,
This could be a solution. Release 1.9 this year (potentially a
Christmas present) with the new features we have now and then 2.0 in
summer or autumn 2013. We could do the feature freeze of 1.9 quite soon.
Andreas
On Thu, 25 Oct 2012 07:50:43 +0200, Marco Hugentobler wrote:
Hi
I
On Thu, Oct 25, 2012 at 12:48 AM, Paolo Cavallini cavall...@faunalia.it wrote:
I'm voting for a polished 2.0 release in a few month with the great feature
set we already have.
+1: let's release ASAP.
-1, of course let's release ASAP, but without creating future problems.
Please note that, as
On Thu, Oct 25, 2012 at 7:50 AM, Marco Hugentobler
marco.hugentob...@sourcepole.ch wrote:
Would it be an option to branch a 1.9 from current master just before Martin
merges the first breaking changes? That way, there would be a version with
all the nice 1.9 features and very little API breaks
Hi all,
I don't know if somebody already brought up this (the discussion is
already rather long), but is there no possibility for including legacy
methods?
For the iterators this would probably mean, that there is a reserved
iterator running single-threaded for any calls to the old API.
I don't
On Thu, Oct 25, 2012 at 09:21:46AM +0200, Radim Blazek wrote:
On Thu, Oct 25, 2012 at 7:50 AM, Marco Hugentobler
marco.hugentob...@sourcepole.ch wrote:
Would it be an option to branch a 1.9 from current master just before Martin
merges the first breaking changes? That way, there would be a
Il 25/10/2012 16:21, Radim Blazek ha scritto:
Very bad idea IMO. That would result exactly in what we don't want:
having multiple broken versions with different (not) working features
available in each one. Again the same problem with breaking API twice,
not enough resources to concentrate on
+1 for a spring or mid 2013 release of 2.0 with API break + plugin task
force. I was afraid that API change could lead to end 2013.
I would be please to support such an effort. I agree we need multithreading
enabled, and a polished API. But I remember the amount of effort needed to
release a
MORREALE Jean Roc wrote
The frequent feedback I get from institutions using QIGS is that they
want :
- bugfixes but no new functionalities
- but new useful functionalities (just for their specific use cases
of course)
- less frequent release to ease the software validation and their
On Thu, Oct 25, 2012 at 12:30 PM, Matthias Kuhn matthias.k...@gmx.ch wrote:
How does the new API handle this?
There is an iterator class that you would use like this:
QgsFeatureIterator it = layer.getFeatures(request)
while (it.nextFeature(f)) { do_something; }
The constructor typically
Hi devs,
My humble opinions :
* We should go for api breakage asap, or we will postpone it next time we
will speak again about it.
* +1 for contacting every plugin author and give them a documentation on
how to migrate their plugins to the new api.
* if plugin authors do not respond, we
Il 25/10/2012, qgis-developer-boun...@lists.osgeo.org ha scritto:
* we could release every 6 month like ubuntu, but I am not sure we have
the
manpower to do so. If yes, this will be the best IMHO
For me it's not a problem if we release every 6 months. The most important
thing is to release
2012/10/25 kimaidou kimai...@gmail.com:
Hum... reading my text above, it sounds too simple : I do not take into
account the need for bug fixing. One year without a bug fix can be very
long. And backporting means to have time and manpower... ARg, stuck again !
But now there are no backports
Il 26/10/2012 07:00, Pedro Venâncio ha scritto:
Hi,
I think this is happening with all the plugins that collect data from raster
layers. For example,
One of these cases where centralized fixes are so much more efficient.
Is anyone wiling to fix them?
Pedro, could you please open tickets
Il 25/10/2012 22:48, Luca Manganelli ha scritto:
For me it's not a problem if we release every 6 months. The most
important thing is to release fixpacks (i.e. 1.7.1, 1.7.2, etc). For
example, we cannot use 1.8.0 because of bugs not present in 1.7.4 and
it seems that we never see a 1.8.1
On some OS it looks like the location of the python bindings to qtsql
has moved and is causing any plugin that imports to fail.
Specifically on ubuntu 12.04 and newer it's inside pyside. I'm not sure
if this affects other systems (Win/Mac). So it might be advised for
plugin authors to do an if
Il 26/10/2012 14:25, Minoru Akagi ha scritto:
Hi,
In Japanese Windows environment, GRASS commands output xml text of interface
description that begins with the following line.
?xml version=1.0 encoding=CP932?
CP932 is the system default encoding of Japanese Windows environment.
17 matches
Mail list logo
