Hi,
In general I like the new icon set, because the icons look slicker and
clearer.
But I just noticed this inconsistency between the Map Navigation
toolbar and the print composer. The pan tool in the Map Navigation
consists of four arrows into all directions. In the print composer it is
one
Hi Matthias and Tim,
As I can see, switching off ML subscription during holidays is not a
good idea ;)
On 26.07.2012 14:10, Matthias Kuhn wrote:
But I just noticed this inconsistency between the Map Navigation
toolbar and the print composer. The pan tool in the Map Navigation
consists of
My answer was too fast...
On 26.07.2012 14:27, Robert Szczepanek wrote:
Hi Matthias and Tim,
On 26.07.2012 14:10, Matthias Kuhn wrote:
But I just noticed this inconsistency between the Map Navigation
toolbar and the print composer. The pan tool in the Map Navigation
consists of four arrows
I don't know much about the memory layer handling - but here are some thoughts:
I think Jürgen's idea makes a lot of sense: keep in-memory spatialite
database, and save/restore when the project is saved/opened. And the
user can export the layer to a preferred format if he/she wishes.
Perhaps
We are designing the raster save as in a way that could be re-used
elsewhere, perhaps vector saving could follow the same route -
although not much (nothing) can be shared between the vector and
raster dialogs.
Etienne
On Thu, Jul 26, 2012 at 2:29 AM, Paolo Cavallini cavall...@faunalia.it wrote:
On Thu, Jul 26, 2012 at 3:14 AM, Marco Hugentobler
marco.hugentob...@sourcepole.ch wrote:
Hi Etienne
What I have done for the format options is make is a standalone
widget, and it is included in the file save as dialog and gdal
options, as well as in the gdaltools dialogs (overviews only for
Hi Robert,
I like the consistent look of your icon set. The results of Tim's poll
clearly show many wish to switch to your set right away [0].
Since QGIS is icon- and toolbar-heavy in overall look (in default
configuration), whatever you can do to improve the definitive visual
change from the
Hi,
my opinion is somewhere between Larry's and Yve's..
GIS theme has two main drawbacks IMHO:
1. Global render of toolbars is a cold blue - gray, in opposite of all QGIS
relate support, that are colorfull (sites, GUI). It looks very old school
GIS to me.. My wife, who likes painting, and
Hi
On Thu, Jul 26, 2012 at 7:27 PM, Larry Shaffer lar...@dakotacarto.com wrote:
Hi Robert,
I like the consistent look of your icon set. The results of Tim's poll
clearly show many wish to switch to your set right away [0].
Since QGIS is icon- and toolbar-heavy in overall look (in default
Hi all.
Now that there is much work on refactoring the raster classes, wouldn't
it be the right time to implement a series of colour ramps to be
applied, instead of having only the current ugly blue-red one, based on
equal intervals? The 1-band plugin is a very good guidance for this.
The current
I was thinking about that, we could leverage the existing colorramps
for vectors.
We should probably refactor QgsVectorColorRampV2 as QgsColorRamp, and
if need be create 2 subclasses (vector, raster). We could probably
use existing dialogs pretty easily also, and do the same.
Unless there is a
Il 26/07/2012 21:14, Etienne Tourigny ha scritto:
I would colunteers to so this work - I just need a little guidance on
overall implementation details.
That would be great, merci Etienne.
In this case, I think we should add several ramps that, although useful
for both, are really necessary for
Hi Etienne,
In this case, I think we should add several ramps that, although useful
for both, are really necessary for raster (e.g. DTM). See 1-band plugin
for a very nice set of ramps, and classification methods.
From the user point of view, having the same colours available would be
a
On Thu, Jul 26, 2012 at 4:25 PM, Giovanni Manghi
giovanni.man...@faunalia.pt wrote:
Hi Etienne,
In this case, I think we should add several ramps that, although useful
for both, are really necessary for raster (e.g. DTM). See 1-band plugin
for a very nice set of ramps, and classification
Il 26/07/2012 21:29, Etienne Tourigny ha scritto:
Is there anything in the vector color ramps that should NOT be
available for raster color ramps?
I think they will not hurt, and often can be useful. Of course, if you
are going to implement 20 ramps, a classification/tagging/tree method
will be
Hi Even
Thanks for the suggestion and code examples - very helpful. I haven't followed
up on this yet partly because this has prompted me to look at other storage
formats for the data (something I'd been putting off).
If I understand the GML driver documentation properly then I would have to
Hi
On Thu, Jul 26, 2012 at 9:29 PM, Etienne Tourigny
etourigny@gmail.com wrote:
On Thu, Jul 26, 2012 at 4:25 PM, Giovanni Manghi
giovanni.man...@faunalia.pt wrote:
Hi Etienne,
In this case, I think we should add several ramps that, although useful
for both, are really necessary for
Le jeudi 26 juillet 2012 21:41:57, Chris Crook a écrit :
Hi Even
Thanks for the suggestion and code examples - very helpful. I haven't
followed up on this yet partly because this has prompted me to look at
other storage formats for the data (something I'd been putting off).
If I
Good points. I'm thinking perhaps the solution is to use Sqlite/spatialite
(don't get me wrong - I like and use spatialite a lot). But perhaps use the
python spatialite driver directly, rather than the QgsVectorFileWriter class as
I am currently doing, as I cannot see any OGR options for
On Thu, Jul 26, 2012 at 1:40 PM, Paolo Cavallini cavall...@faunalia.it wrote:
Il 26/07/2012 21:29, Etienne Tourigny ha scritto:
Is there anything in the vector color ramps that should NOT be
available for raster color ramps?
Beware that many ramps have a meaning only when applied to absolute
Le jeudi 26 juillet 2012 22:52:47, Chris Crook a écrit :
Hi Even
Sorry .. lost wasn't quite correct. The point is that my code for saving
some users data and then reloading needs to take account of whether they
have a field called fid or not if I want the list of fields unchanged
after
21 matches
Mail list logo
