Re: [QGIS-Developer] QGIS project maintainability, forms and styles, xml verbosity (Nyall Dawson)

[Alister Hood via QGIS-Developer]

Hi, at least a couple of other ideas have been suggested that could help
reduce the amount of project xml in many cases:
Live linked layer styles · Issue #17898 · qgis/QGIS (github.com)

"Embedded styling" option for paletted raster layers · Issue #53453 ·
qgis/QGIS (github.com) 

Regards,
Alister
___
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] Are standard processing post-execution scripts not supported in QGIS3?

[Alister Hood via QGIS-Developer]

Hi,
This is included in the documentation:
17.28. Pre- and post-execution script hooks — QGIS Documentation
documentation


But it seems to me that although ProcessingConfig.POST_EXECUTION_SCRIPT
and ProcessingConfig.PRE_EXECUTION_SCRIPT exist in QGIS3, they're actually
not used for anything.  Is this right, or am I missing something?

Note that the code in the examples seems to be for QGIS2 (although even
there it doesn't work in Windows, unless I switch from shutil copytree to
distutils.dir_util copy_tree).

Thanks,
Alister
___
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] Best practice for plugins including processing models

[Alister Hood via QGIS-Developer]

And including this in loadModels() is a fairly safe way to remove the
copied model files from previous versions:

modelsFiles = glob.glob(os.path.join(self.modelsPath,
'*.model3'))

for modelFileName in modelsFiles:
destFilename =
os.path.join(ModelerUtils.defaultModelsFolder(),
os.path.basename(modelFileName))
try:
if os.path.exists(destFilename):
move(destFilename, destFilename + '.bak')
except Exception as ex:
QgsMessageLog.logMessage(self.tr('Failed to rename
existing model: {} - {}'.format(destFilename, str(ex))), self.messageTag,
Qgis.Warning)
continue

It does mean that if someone happens to have a model with the same name as
one provided by the plugin, it will disappear, but at least it will still
be there as a *.bak file, rather than just being overwritten.

On Tue, 16 May 2023 at 13:19, Alister Hood  wrote:

> Further to this, I am now using the following code to load the models
> directly from the plugin folder, rather than copying them into
> %AppData%\Roaming\QGIS\QGIS3\profiles\default\processing\models
>
>
> def loadModels(self):
> modelsFolders=ModelerUtils.modelsFolders()
> if self.modelsPath not in modelsFolders:
> modelsFolders.append(self.modelsPath)
>
> ProcessingConfig.setSettingValue(ModelerUtils.MODELS_FOLDER,
> ';'.join(modelsFolders))
>
> QgsApplication.processingRegistry().providerById('model').refreshAlgorithms()
>
> def unloadModels(self):
> modelsFolders=ModelerUtils.modelsFolders()
> if self.modelsPath in modelsFolders:
> modelsFolders.remove(self.modelsPath)
>
> ProcessingConfig.setSettingValue(ModelerUtils.MODELS_FOLDER,
> ';'.join(modelsFolders))
>
> QgsApplication.processingRegistry().providerById('model').refreshAlgorithms()
>
>
> On Fri, 28 Apr 2023 at 15:07, Alister Hood  wrote:
>
>> Hi, I maintain an in-house plugin for our team of civil engineers, who
>> apart from myself are not very advanced GIS users.
>> It does things like set useful defaults and install a set of useful
>> plugins.  It also includes some processing models, which are loaded with
>> the code below, which seems to be the conventional way models are loaded in
>> publicly available plugins which ship processing models.  This code copies
>> the model files included in the plugin to the default folder for processing
>> models - somewhere like
>> %AppData%\Roaming\QGIS\QGIS3\profiles\default\processing\models
>>
>> One of my colleagues did some QGIS training and created a processing
>> model, which coincidentally had the same filename as a model I created on
>> the same day, so his model got overwritten when my plugin was updated.
>> This is not a problem for us as we are a small team and can be careful what
>> we do going forward.  But it highlights that the way plugin authors are
>> loading model files is what seems to me to be pretty poor practice, for two
>> reasons.
>>
>> Firstly models are available in qgis even when the plugin is unloaded or
>> uninstalled, which is probably not desirable.
>> It is trivial to implement an unloadModels function to rectify this, and
>> I have done so in my in-house plugin.  I'm wondering - should plugin
>> authors be encouraged to do the same?
>>
>> Secondly, loading the plugin will silently overwrite any existing models
>> with the same filename, as occurred here.  Plugins generally contain models
>> with fairly special filenames, so hopefully this is unlikely to occur,
>> unless:
>> - someone produces a plugin that is a fork of another one, or
>> - someone ships a plugin with a model that is previously publicly
>> available somewhere else, or that was created by following an online
>> tutorial, or
>> - a user edits a model provided by a plugin.
>> In any case, would it be a good idea to encourage plugin authors to load
>> models another way, without copying them into
>> %AppData%\Roaming\QGIS\QGIS3\profiles\default\processing\models?
>> I realise that to change an existing plugin there is the added
>> complication of what to do when updating from an old version - the only
>> safeish way I can think of to automatically clean up obsolete model files
>> would be to check for them and then use a checksum to verify whether they
>> should be deleted.
>> For what it's worth, I note that when a user tries to manually "add model
>> to toolbox", QGIS refuses if there is an existing model with the same

Re: [QGIS-Developer] Best practice for plugins including processing models

[Alister Hood via QGIS-Developer]

Further to this, I am now using the following code to load the models
directly from the plugin folder, rather than copying them into
%AppData%\Roaming\QGIS\QGIS3\profiles\default\processing\models


def loadModels(self):
modelsFolders=ModelerUtils.modelsFolders()
if self.modelsPath not in modelsFolders:
modelsFolders.append(self.modelsPath)

ProcessingConfig.setSettingValue(ModelerUtils.MODELS_FOLDER,
';'.join(modelsFolders))

QgsApplication.processingRegistry().providerById('model').refreshAlgorithms()

def unloadModels(self):
modelsFolders=ModelerUtils.modelsFolders()
if self.modelsPath in modelsFolders:
modelsFolders.remove(self.modelsPath)

ProcessingConfig.setSettingValue(ModelerUtils.MODELS_FOLDER,
';'.join(modelsFolders))

QgsApplication.processingRegistry().providerById('model').refreshAlgorithms()


On Fri, 28 Apr 2023 at 15:07, Alister Hood  wrote:

> Hi, I maintain an in-house plugin for our team of civil engineers, who
> apart from myself are not very advanced GIS users.
> It does things like set useful defaults and install a set of useful
> plugins.  It also includes some processing models, which are loaded with
> the code below, which seems to be the conventional way models are loaded in
> publicly available plugins which ship processing models.  This code copies
> the model files included in the plugin to the default folder for processing
> models - somewhere like
> %AppData%\Roaming\QGIS\QGIS3\profiles\default\processing\models
>
> One of my colleagues did some QGIS training and created a processing
> model, which coincidentally had the same filename as a model I created on
> the same day, so his model got overwritten when my plugin was updated.
> This is not a problem for us as we are a small team and can be careful what
> we do going forward.  But it highlights that the way plugin authors are
> loading model files is what seems to me to be pretty poor practice, for two
> reasons.
>
> Firstly models are available in qgis even when the plugin is unloaded or
> uninstalled, which is probably not desirable.
> It is trivial to implement an unloadModels function to rectify this, and I
> have done so in my in-house plugin.  I'm wondering - should plugin authors
> be encouraged to do the same?
>
> Secondly, loading the plugin will silently overwrite any existing models
> with the same filename, as occurred here.  Plugins generally contain models
> with fairly special filenames, so hopefully this is unlikely to occur,
> unless:
> - someone produces a plugin that is a fork of another one, or
> - someone ships a plugin with a model that is previously publicly
> available somewhere else, or that was created by following an online
> tutorial, or
> - a user edits a model provided by a plugin.
> In any case, would it be a good idea to encourage plugin authors to load
> models another way, without copying them into
> %AppData%\Roaming\QGIS\QGIS3\profiles\default\processing\models?
> I realise that to change an existing plugin there is the added
> complication of what to do when updating from an old version - the only
> safeish way I can think of to automatically clean up obsolete model files
> would be to check for them and then use a checksum to verify whether they
> should be deleted.
> For what it's worth, I note that when a user tries to manually "add model
> to toolbox", QGIS refuses if there is an existing model with the same
> filename.
>
> Thanks.
>
>
> def loadModels(self):
> '''Register models present in models folder of the plugin.'''
> try:
> iface.initializationCompleted.disconnect(self.loadModels)
> except:
> pass
>
> #QgsMessageLog.logMessage(self.tr('testing'),
> self.messageTag, Qgis.Warning)
> modelsFiles = glob.glob(os.path.join(self.modelsPath,
> '*.model3'))
>
> for modelFileName in modelsFiles:
> alg = QgsProcessingModelAlgorithm()
> if not alg.fromFile(modelFileName):
> QgsMessageLog.logMessage(self.tr('Not well formed
> model: {}'.format(modelFileName)), self.messageTag, Qgis.Warning)
> continue
>
> destFilename =
> os.path.join(ModelerUtils.modelsFolders()[0],
> os.path.basename(modelFileName))
> try:
> if os.path.exists(destFilename):
> os.remove(destFilename)
>
> if isWindows():
> copyfile(modelFileName, destFilename)
> else:
>   

[QGIS-Developer] Best practice for plugins including processing models

[Alister Hood via QGIS-Developer]

Hi, I maintain an in-house plugin for our team of civil engineers, who
apart from myself are not very advanced GIS users.
It does things like set useful defaults and install a set of useful
plugins.  It also includes some processing models, which are loaded with
the code below, which seems to be the conventional way models are loaded in
publicly available plugins which ship processing models.  This code copies
the model files included in the plugin to the default folder for processing
models - somewhere like
%AppData%\Roaming\QGIS\QGIS3\profiles\default\processing\models

One of my colleagues did some QGIS training and created a processing model,
which coincidentally had the same filename as a model I created on the same
day, so his model got overwritten when my plugin was updated.  This is not
a problem for us as we are a small team and can be careful what we do going
forward.  But it highlights that the way plugin authors are loading model
files is what seems to me to be pretty poor practice, for two reasons.

Firstly models are available in qgis even when the plugin is unloaded or
uninstalled, which is probably not desirable.
It is trivial to implement an unloadModels function to rectify this, and I
have done so in my in-house plugin.  I'm wondering - should plugin authors
be encouraged to do the same?

Secondly, loading the plugin will silently overwrite any existing models
with the same filename, as occurred here.  Plugins generally contain models
with fairly special filenames, so hopefully this is unlikely to occur,
unless:
- someone produces a plugin that is a fork of another one, or
- someone ships a plugin with a model that is previously publicly available
somewhere else, or that was created by following an online tutorial, or
- a user edits a model provided by a plugin.
In any case, would it be a good idea to encourage plugin authors to load
models another way, without copying them into
%AppData%\Roaming\QGIS\QGIS3\profiles\default\processing\models?
I realise that to change an existing plugin there is the added complication
of what to do when updating from an old version - the only safeish way I
can think of to automatically clean up obsolete model files would be to
check for them and then use a checksum to verify whether they should be
deleted.
For what it's worth, I note that when a user tries to manually "add model
to toolbox", QGIS refuses if there is an existing model with the same
filename.

Thanks.


def loadModels(self):
'''Register models present in models folder of the plugin.'''
try:
iface.initializationCompleted.disconnect(self.loadModels)
except:
pass

#QgsMessageLog.logMessage(self.tr('testing'), self.messageTag,
Qgis.Warning)
modelsFiles = glob.glob(os.path.join(self.modelsPath,
'*.model3'))

for modelFileName in modelsFiles:
alg = QgsProcessingModelAlgorithm()
if not alg.fromFile(modelFileName):
QgsMessageLog.logMessage(self.tr('Not well formed
model: {}'.format(modelFileName)), self.messageTag, Qgis.Warning)
continue

destFilename =
os.path.join(ModelerUtils.modelsFolders()[0],
os.path.basename(modelFileName))
try:
if os.path.exists(destFilename):
os.remove(destFilename)

if isWindows():
copyfile(modelFileName, destFilename)
else:
os.symlink(modelFileName, destFilename)
except Exception as ex:
QgsMessageLog.logMessage(self.tr('Failed to install
model: {} - {}'.format(modelFileName, str(ex))), self.messageTag,
Qgis.Warning)
continue


QgsApplication.processingRegistry().providerById('model').refreshAlgorithms()
___
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] Does QgsProject.instance().createEmbeddedGroup() work? (Solved: yes it does)

[Alister Hood via QGIS-Developer]

Ah, sorry.
I misunderstood what it does  - I was thinking I could specify an arbitrary
groupName which it would create and load the layers in projectFilePath
into.
groupName is actually meant to be an existing group in projectFilePath, and
it loads that.

Thanks.


>
> Date: Mon, 19 Sep 2022 09:08:02 +0200
> From: Johannes Kr?ger (WhereGroup)  
> To: qgis-developer@lists.osgeo.org
> Subject: Re: [QGIS-Developer] Does
> QgsProject.instance().createEmbeddedGroup() work?
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Hi Alister,
>
>
> https://qgis.org/pyqgis/master/core/QgsProject.html#qgis.core.QgsProject.createEmbeddedGroup
> and
>
> https://api.qgis.org/api/classQgsProject.html#ad2e059da29ebfc32096367abb78da46c
> say it should return a QgsLayerTreeGroup so I guess it is broken, at
> least documentation-wise.
>
> https://api.qgis.org/api/qgsproject_8cpp_source.html#l03274 on the other
> hand hints at several "return nullptr" so it returning None is by
> design. The code seems fairly readable and even has useful comments so
> maybe check if one of the cases might be true in your testcase.
>
> Cheers, Hannes
>
> Am 19.09.22 um 05:40 schrieb Alister Hood via QGIS-Developer:
> > Hi, I want to programmatically embed a project, like I can in the gui
> > with "Layer>embed layers and groups."
> >
> > I thought QgsProject.instance().createEmbeddedGroup() was what I
> > needed, but it doesn't seem to work - see below.? Am I completely off
> > track, or is it broken?
> >
> > Thanks.
> >
> > path='/home/alister/testtoembed.qgs'
> > project = QgsProject.instance()
> > project.read(path)
> > True
> > project.clear()
> > newGroup = QgsLayerTreeGroup()
> > type(newGroup)
> > 
> > newGroup = QgsProject.instance().createEmbeddedGroup('test', path, [])
> > type(newGroup)
> > 
> >
> > ___
> > 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
>
> --
> Johannes Kr?ger / GIS-Entwickler/-Berater
>
___
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] Does QgsProject.instance().createEmbeddedGroup() work?

[Alister Hood via QGIS-Developer]

Hi, I want to programmatically embed a project, like I can in the gui with
"Layer>embed layers and groups."

I thought QgsProject.instance().createEmbeddedGroup() was what I needed,
but it doesn't seem to work - see below.  Am I completely off track, or is
it broken?

Thanks.

path='/home/alister/testtoembed.qgs'
project = QgsProject.instance()
project.read(path)
True
project.clear()
newGroup = QgsLayerTreeGroup()
type(newGroup)

newGroup = QgsProject.instance().createEmbeddedGroup('test', path, [])
type(newGroup)

___
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] WSLg

[Alister Hood]

For anyone who is tempted to "look", be aware that although Microsoft
hasn't encouraged it, it has been possible for years to run X apps and even
audio apps (using pulseaudio) in WSL.  This new "WSLg" might provide nice
out-of-the-box support, but it only works with WSL-2, which still has some
major downsides compared to WSL-1, so depending on what you want to do, you
might be better off with an old WSL-1 system.
1. WSL2 is touted as having better performance, but this relates to doing
things inside the Linux system.  It is apparently much slower for accessing
files in the windows system, so that is officially discouraged
2. It grows to take up all your disk space:
https://github.com/microsoft/WSL/issues/4699

Regards,
Alister



> Date: Sun, 20 Jun 2021 12:08:33 +0100
> From: Tim Sutton 
> To: Gandalf the Gray 
> Cc: qgis-dev 
> Subject: Re: [QGIS-Developer] WSLg
> Message-ID:
> <
> caes-dzr7gmzmtop-d+okzt2t52veclgx_lb358jksh3m2n3...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Nice! And to balance out the universe, you can also run the windows build
> under wine (
> https://gist.github.com/timlinux/8f5e76f3f5d7c10042356e0aa1da7676).
>
> Regards
>
> Tim
>
> On Sat, Jun 19, 2021 at 8:50 AM Gandalf the Gray 
> wrote:
>
> > MS has rolled out WSLg (https://github.com/microsoft/wslg)  which
> > includes support for Wayland and X11).
> >
> > There are even drivers from Nvidia, Intel and AMD that works with this.
> >
> > I have tried some graphics applications Iincluding QGIS, and I am really
> > surprised.
> >
> > Really worth a look
>
___
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] GSoC 2021 QGIS On-the-fly Raster Calculator proposal draft review and feedback

[Alister Hood]

Hi again,

On Wed, 14 Apr 2021 at 01:40, Francesco Bursi 
wrote:

> Hi Alister,
>
> Thank you for the feedback.
> Well, I imagine the new feature with some properties of the existing
> Raster Calculator but not exactly the same, e.g It won't be possible to set
> layer extent / output CRS, because this would be already pre-defined by the
> layer on which the renderer is applied, in the basic mockup you should not
> see these 2 field. The same can be said for choosing other layer. It should
> work like contours/hillshade renderer, where you can style only the layer
> you have currently selected but you can choose the band.
>

Ah, the proposed calculator renderer wouldn't be able to calculate from
more than one layer.  That's an important clarification, and it means it is
a lot less useful than I thought it might have been.

I use the raster calculator mostly to calculate the difference between two
layers, both for visualisation and to display values in the value tool
plugin.  I create the rasters as temporary files, to avoid storing lots of
large raster files that are simple to regenerate if necessary.  The
downside of doing this is that if necessary I do actually need to
regenerate them .

A "virtual raster" provider would allow me to keep them around without
eating up disk space.  I imagine use cases like this are quite common.

Besides, I think that the existing Raster Calculator in the processing
> toolbox (as well as the Gdal Raster Calculator) allows the creation of a
> temporary file, enable the addition of a layer to the project that you can
> style, but maybe here I misunderstood what you meant.
>

Yes, but temporary files are obviously inconvenient enough to motivate you
to implement an on-the-fly raster calculator renderer :)


> One of the advantage of the on-the-fly (styling) is to  * avoid the need
> to create derived raster files and layers.*
>

What I'm suggesting is that a slightly more general solution would be
useful in more situations.  In your words, it would "avoid the need to
create derived raster files" in a lot more situations.

The only downside is that the virtual raster would be created as a new
layer in the QGIS project (if you want to reduce this "clutter", you might
just be able to remove the original layer from the project, but sometimes
you would want to keep it for other reasons).  But it is normal to have
extra layers in your project just to get things to display you want - for
example I imagine it is very common for people to duplicate a raster layer
so they can display it both with the hillshade renderer and one or more
other renderers.

In any case, assuming you do follow the symbology approach rather than a
provider, as a user I'd still ask if the way you're proposing to implement
this is really the best way. Rather than adding a new render type, from a
user's perspective I think it would be a lot simpler to instead add a Σ
button next to all of the "band" comboboxes, allowing you to enter a raster
calculator expression rather than selecting a band.  This approach would be
consistent with the "value" comboboxes for selecting a field from a vector
layer, which have a Σ button next to them, and it could also be extended to
anywhere else in QGIS where you select a raster band.

Regards,
Alister

>
___
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] GSoC 2021 QGIS On-the-fly Raster Calculator proposal draft review and feedback

[Alister Hood]

>
> Hi,
This functionality would be great, but as a user, I can't help thinking the
proposal is to implement it in the wrong way.

If implemented as a renderer, as described, you could conceivably use an
expression that uses other layers but not the layer you are supposedly
rendering.  What is displayed would not correspond in any way to the actual
layer... Bizarre.

Would it not be possible to instead implement a "virtual raster"
*provider*?  Add a checkbox in the raster calculator labelled "create as
virtual raster".  Create a new layer that can be styled using the existing
renderers and behaves in every way like a non-virtual layer - e.g. the
right values would be shown using the identify tool and the "value tool"
plugin, and you could use the layer as an input for other processing tools.

Regards, and best wishes with the proposal,
Alister

Date: Mon, 12 Apr 2021 12:20:53 +
> From: Francesco Bursi 
> To: qgis-developer 
> Subject: [QGIS-Developer] GSoC 2021 QGIS On-the-fly Raster Calculator
> proposal draft review and feedback
> Message-ID:
> <
> vi1p190mb038187bb910511b3b6b8b44280...@vi1p190mb0381.eurp190.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="windows-1252"
>
> Hello QGIS Dev,
>
>
> I?m Francesco Bursi, an M.Sc. civil engineer from Italy currently enrolled
> in a Master of Advanced Studies (Level 8 EQF) in giscience and
> geoinformatics at the University of Padua.
>
> I?m really interested in the QGIS (possible) new rendering feature that
> involves raster calculator capabilities, I've already discussed the project
> with mentors Martin Tobias and Peter Petrik and possible co-mentor Roberto
> Marzocchi,  they gave me a lot of feedback and advice for the project.
> I would like to share my proposal with you before the final submission.
> Don't hesitate to give me feedback and ask me question/clarification or
> point me out what's missing.
>
>
> proposal 2021<
> https://docs.google.com/document/d/1u8L_L1IJjGCZ3d8Vq8duxHbsHZeyzwqOe3tXa1JcKbs/edit?usp=sharing
> >
>
>
> I'm open to advice, remarks and criticism in order to improve.
>
> I am looking forward to a feedback, thank you for your time.
>
>
> Best regards,
>
> Francesco Bursi
___
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] Agreement

[Alister Hood]

Hi Chris,
If you're looking for suggestions on what part of the code to start with,
maybe it is worth looking at the list of issues tagged "easy fix", although
it looks like it isn't really maintained:
https://github.com/qgis/QGIS/issues?q=is%3Aopen+is%3Aissue+label%3A%22Easy+fix%22

Regards,
Alister

From: Peter Petrik 
> To: ch...@clandegrassi.com
> Cc: qgis-developer 
> Subject: Re: [QGIS-Developer] Agreement
> Message-ID:
>  zgy...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Chris and welcome to the team.
>
> Now when you create a pull request, we will review it and give you
> feedback. If you are stuck, feel free to write to the mailing list or
> chat(s) and seek for the help. Best is to start with some easy bug fixes in
> the area of the code you would like to contribute to.
>
> Kind regards,
> Peter
>
> On Tue, Mar 2, 2021 at 4:12 AM  wrote:
>
> >
> > Hello,
> > I apologize in advance if this is going to the wrong place.
> >
> > I have read the New Developer Requirements at
> >
> >
> https://www.qgis.org/en/site/getinvolved/development/contributor_requirements.html
> > and I agree to the Code(s).
> >
> > I am a Software Engineer/GIS Analyst and I would like to contribute to
> > QGIS.
> > I have cloned the repository and successfuly completed the buid following
> > the posted document.
> > I can help with bugs, new code and Plugins.
> >
> > Please let me know how to proceed.
> >
> > Thank you
> > Cheers
> > Chris Degrassi
>
___
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 disables plugin on loading problem

[Alister Hood]

I know the thread's a few days old now, but maybe it's worth mentioning
that I see the opposite problem - i.e. plugins loading when they are
supposed to be disabled.

For example, I think it is QAD that loads (toolbars and all), even if it is
disabled in the plugin manager.

There are other plugins that do the same thing, and it is particularly
annoying if they are and producing errors for whatever reason.  QGIS
continues to try to load them at every startup - it doesn't seem possible
to disable them, only to uninstall them.

At least some plugins (crayfish I think was the one where I noticed it)
produce errors if they are installed but not supported by your QGIS
version, even though they don't claim to be supported.  i.e. crayfish (I
think) claims to require QGIS 3.13, but if you have it installed and you
start QGIS 3.12 for some reason that still tries to load crayfish, and
produces an error.  Surely QGIS should ignore the plugin if it doesn't
claim to be compatible it, or at most show a notification about it,
instead  of erroring

These behaviours make me think there is something wrong with the way QGIS
loads plugins, but may they are normal.  Do they indicate problems with the
plugin, not with QGIS?

Regards,
Alister

Date: Thu, 3 Dec 2020 08:21:20 +0100
> From: Luca Manganelli 
> To: QGIS Developer List 
> Subject: [QGIS-Developer] QGIS disables plugin on loading problem
> Message-ID:
> <
> cagkduj1jjekgcqhrd13uy-hbpf9jnm8gyfervrcuzh5eusz...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello,
>
> by default behavoiur, QGIS disables plugin when there's a loading problem
> with it.
>
> In a corporate environment, we have custom plugins that are loaded for a
> shared local network folder. If the network is down and one user loads
> QGIS, it disables the plugin loaded from the local network now and in the
> future.
>
> Is there any way to disable this behaviour? (QGIS 2 doesn't do it).
>
___
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 authors - can/should you all give your plugin toolbars a tooltip?

[Alister Hood]

Hi everyone,

As described in this old ticket:

https://github.com/qgis/QGIS/issues/17019
"With a lot of plugins installed, the number of toolbars and panels soon
reach a confusing stage where users would like to be able to easily clean
and adjust their working environment according to their actual
needs.Disabling/enabling toolbars is a trial-and-error game, cause it's not
easy to identify which toolbar has which name in the list.
In addition to that, the dropdowns close after disabling/enabling each
single item, so adjusting toolbars/panels needs a lot of repetitive actions
(and even more of them, when the wrong toolbar/panel was chosen
beforehand)."

QGIS does now display tooltips on the handles of the built-in toolbars, but
none of the plugin toolbars I see have tooltips yet.  I doubt there is any
reason they shouldn't - it's probably just that the plugin builder doesn't
include the code for it.

If you maintain a plugin which provides a toolbar, it seems that the fix is
typically as simple as adding something like this in your plugin __init__
where you create the toolbar:
self.toolbar.setToolTip(u'FlowEstimator Toolbar')
I'm sure there are plenty of users like me who will appreciate it if
everyone starts doing this!


Thanks,
Alister
___
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] Incorrect hidpi setting in 3.0 for OSX

[Alister Hood]

Hi Nyall,

Nyall Dawson wrote:

What I can't work out is why Qt widgets themselves badly handle hidpi
> screens. E.g. a QDockWidget on hidpi has a TINY close button. I think
> that needs fixing in Qt itself though, and until they do we just learn
> to squint... but we DON'T try to hack around it using the pixel ratio
> settings.
>
> I also can't work out how to automatically scale layout
> padding/margins by font metrics. It seems a huge endeavour to manually
> set all these... yet without doing so the layouts on hidpi look very
> cramped because widgets a smooshed up against each other with barely
> any padding.
>
> Bah. I wish my laptop could run natively in a low dpi mode with the
> correct aspect ratio. I'd just do that until Qt gets its mess sorted
> out.
>

What you call "low dpi" really isn't that low, and you might want to test
true "low dpi" setups as well as the "high dpi".
I have an arch linux box connected to my TV which IIRC is about 21DPI.
I haven't been able to build QGIS master on that machine, but I gave up on
trying to get other QT5 programs to render properly - using qt5ct I can
almost get them to work, but some widgets and text are microscopic.
FWIW QT5 isn't alone with its problems - if I set the dpi correctly (which
also requires using extremely large fonts) there are also major problems with
programs like Libreoffice and Opera and Seamonkey if it is using GTK3 -
i.e. some  widgets and fonts are microscopic or giant.
___
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] v.triangle for QGIS GRASS (TIN interoplation with breaklines)

[Alister Hood]

Hi Joh, I don't think anyone replied yet, did they?  I'm not sure that your
message is clear.

Date: Tue, 6 Feb 2018 16:42:29 +0100 (CET)
> From: Johann Debril 
> To: qgis-developer@lists.osgeo.org
> Subject: [QGIS-Developer] v.triangle for QGIS GRASS (TIN interoplation
> withbreaklines)
> Message-ID:
> <1348777834.1613455.1517931749495.JavaMail.zimbra@
> lannion-tregor.com>
> Content-Type: text/plain; charset="utf-8"
>
> New modul for grass in qgis proposal :
>

Are you just suggesting this feature (I agree, it seems like it would be
nice to have, particularly in the processing toolbox), or would you propose
to do something to implement it?


> v.triangle
>
> Author : Alexander Muriy
> Interface for Jonathan Richard Shewchuk's Triangle program available on
> http://www.cs.cmu.edu/%7Equake/triangle.html
> Permit TIN interpolation with breaklines


Note that v.triangle itself is not distributed with GRASS and therefore
QGIS, as it has been deemed to be incompatible with the GPL.
The GRASS wiki states that it "is not free for commercial use", but this
appears to be an exaggeration - the homepage says it "may not be sold or
included in commercial products without a license", so commercial use is
OK, just not commercial distribution.

Regards,
Alister
___
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] Ticket cleanup after 2.0 release

[Alister Hood]

> Date: Mon, 09 Sep 2013 14:01:58 +0200
> From: Matthias Kuhn 
> To: Werner Macho 
> Cc: qgis-developer 
> Subject: Re: [Qgis-developer] Ticket cleanup after 2.0 release
> Message-ID: <522db8b6.3030...@gmx.ch>
> Content-Type: text/plain; charset=UTF-8
>
> +1, I also like this idea.
>
> I would also like to reintroduce the idea of auto-closing tickets which
> are in "Feedback" state for more than 2 weeks to keep the count low in
> the future. Issues in "Feedback" state should be treated as "cannot be
> solved with the current amount of information" and therefore shouldn't
> be crowding the overview of active tickets until somebody provides the
> missing bits.

-1 to this too.

When a ticket is marked as "Feedback", even if the user provides the
feedback requested, they do not have the power to change the status
from "Feedback" to anything except "Closed", so currently this would
result in closing a lot of tickets which shouldn't be closed.
If that is fixed then this idea might be OK, but it might not be
necessary, because the list of tickets marked as "Feedback" should
reduce a lot if tickets don't stay marked as "Feedback" even after the
feedback has been provided...
Also, how about allowing more than 2 weeks; perhaps 1 or 2 months?

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

Re: [Qgis-developer] Ticket cleanup after 2.0 release

[Alister Hood]

> Date: Mon, 09 Sep 2013 13:48:40 +0200
> From: Pirmin Kalberer 
> To: qgis-developer 
> Subject: [Qgis-developer] Ticket cleanup after 2.0 release
> Message-ID: <2701158.lVe8roQyU2@robbe2>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
> With currently ~1700 open bug and feature request tickets, keeping track of
>
> open tickets gets harder and harder. Since many tickets are quite old, maybe
>
> solved or not appropriate anymore, I propose a cut following the 2.0
> release.
> Means we close all tickets with a comment asking to reopen, if the ticket
> still applies to 2.0.

-1

Do you really think there is a large number of open tickets which are
no longer applicable?  It seems unlikely to me.

Also, I'd note that biggest difficulty when searching existing tickets
before filing a new one is that it is impossible to _search_ only open
tickets.  (Last time I checked this was an open ticket for redmine - I
haven't checked whether there is a new version which implements it).

BTW, looking at a couple of my closed tickets, it looks like users do
now actually have the power to reopen their closed tickets, which was
a problem in the past.  Do we know if this is working reliably
everywhere now?

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

Re: [Qgis-developer] right-click to end the digitizing

[Alister Hood]

Hi guys,

> Date: Thu, 25 Jul 2013 07:38:08 -0600
> From: antoniolocandro 
> To: etourigny@gmail.com, denis.rouz...@gmail.com
> Cc: qgis-developer@lists.osgeo.org,
> regis.haubo...@eau-adour-garonne.fr
> Subject: Re: [Qgis-developer] right-click to end the digitizing
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"
> 
> I do a lot of digitising and +1 for right clic finish only unless you add 
> other actions to right clic like snap to midpoint, snap to edge, etc like 
> other software then my vote would > g8 to double click to finish feature or 
> f2 if that's not patented?

Yes, there are two issues here.
Firstly, it should definitely be possible to finish digitising a feature 
without adding an additional point.  And I think at least for the sake of new 
or casual users this should be the default.
Secondly, I think even if it doesn't happen now, eventually there should be a 
menu on right-click, for things like undoing the last vertex.  I think a little 
while ago there was some discussion of this along with right-click menus in the 
composer, but maybe it was just me ;)

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

Re: [Qgis-developer] Splash screen for 2.0

[Alister Hood]

Hi guys,
Tim is right about the logo orientation - there's no reason to put it on a 
lean.  Even in the versions with the arrow pointing at the mountain it would 
look far more sensible if you reposition and/or resize it so that it is 
vertical.

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

Re: [Qgis-developer] Splash screen for 2.0

[Alister Hood]

And isn't "Quantum" supposed to be done away with?

- Alister

> Date: Mon, 15 Jul 2013 08:50:07 +1000
> From: Nathan Woodrow 
> To: Tim Sutton 
> Cc: "qgis-developer@lists.osgeo.org" 
> Subject: Re: [Qgis-developer] Splash screen for 2.0
> Message-ID:
>   
> Content-Type: text/plain; charset="iso-8859-1"
> 
> >>> I put together a splash mock up here:
> https://dl.dropboxusercontent.com/u/1166848/splash.png - please commence
> flaming :-)
> 
> I don't mind the background idea, but I was just thinking why not get some
> data of the area and make a map using QGIS itself for the splash.  We can
> make some impressive looking maps now with all the great new features it
> only seems fitting that we show them off in the splash screen.
> 
> It would be good to find a nice new modern font and change the colour as
> that mockup makes me feel like I'm living in the 70s.  0_o
> http://uglyhousephotos.com/wordpress/wp-
> content/uploads/2010/07/100718stcharlesil3.jpg
> 
> - Nathan
> 
> 
> On Mon, Jul 15, 2013 at 7:38 AM, Tim Sutton  wrote:
> 
> > Hi
> >
> > I took a look at the various maps linked to. I prefer this on:
> >
> > http://s.geo.admin.ch/09751c84f
> >
> > The large tracts of white in the Siegfriedkarte don't really work for
> > me and I find the above one much more visually interesting and not at
> > all depressing. I also do not think it matters that the word dufour
> > does not exist on the map.
> >
> > I put together a splash mock up here:
> > https://dl.dropboxusercontent.com/u/1166848/splash.png - please
> > commence flaming :-)
> >
> > Regards
> >
> > Tim
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] SEXTANTE: R output?

[Alister Hood]

>Date: Fri, 12 Jul 2013 16:05:21 +0200
>From: Matteo Mattiuzzi 
>To: Victor Olaya 
>Cc: "qgis-developer@lists.osgeo.org" 
>Subject: Re: [Qgis-developer] SEXTANTE: R output?
>Message-ID:
>
>Content-Type: text/plain; charset="iso-8859-1"
>
>>Ok, fine then. Only in the canonical libpath. :-)
>
>Yes I guess it it the saver choice.
>
>>>I think it is (quite) easily possible to remove the need of R knowledge
>>>for a lot of situations, one of these it the installation and update of
>>>packages. It is much easier to share a Rscript (rsx) to another system if
>>>not installed packages are added automatically.
>
>>I agree with that, but what I mean is that the person that writes the
>>script should take care of all the installation/checking/etc code. He
>>should put all that sanity code in his plugin, not expect SEXTANTE to
>>do it, because that makes things less flexible, and it seems that we
>>cannot come to a good solution on that. That's what I meant.
>
>A script writer can care about the own environment but not so much on the
>one of others (just the loading can be handled with ease). R it to much
>modular it is not possible (for what I know) to provide a fully operation
>plugin if a package is not available locally.
>So probably every script need to have in its documentation which library
>has to be present, and a reference to a doc on how to install libraries in
>R. Probably this is a good solution.
>Or/And SEXTANTE provides with a script like the one I have send you with
>the capability to checkout for required packages. So if that script fails
>(the info which library has to be loaded comes from the sript.rsx), the
>info 'can not install package XXX' see doc... would help further to
>manually install.
>But as QGIS is now close to release (for what I know) it could be a
>development that happens after that... (but I don't want to make pressure
>on that!).
>
>I'm always thinking of SEXTANTE as a possibility more for non R-users.
>
>>Of course I like the idea of sharing scripts :-)
>Great count on me! (for all these things!)
>
>Yes I think Error handing (communication) is very important!
>and also an update script could be made that could be started from the
>SEXTANTE options and configuration.


Do any maintenance scripts need to be in the SEXTANTE configuration?
I was suggesting just listing them in the sextante toolbox with any other R 
scripts.

Regarding users sharing their R scripts, shouldn't these be shared through the 
same infrastructure as python scripts and styles and whatever else?  Someone 
was working on that, weren't they?

Regards,
Alister

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

Re: [Qgis-developer] Toolbar and Panel defaults

[Alister Hood]

Hi guys,
I agree with Antonio on both counts.  With the layers panel on the left it 
seems more natural to have the navigation toolbar on the right side of the 
window.  
And yes, if it is possible to have a titlebar on floating toolbars that would 
make it much easier to close toolbars you don't want (sometimes it isn't at all 
obvious which toolbar you are looking at, so you have to go through turning 
them on and off one at a time until you find the right one).

Also, I think this has been suggested previously, but personally I don't think 
the File or the Manage Layers toolbars should be on by default.  They aren't 
like some of the other toolbars which you need to frequently switch between 
different tools, they contain functions which users naturally look for in the 
right place in the menu, and in the case of the Manage Layers toolbar I suspect 
that even for experienced users it is much faster to find the right tool in the 
layer menu than it is to figure out which icon in the toolbar is the one they 
want.

Regards,
Alister


> Date: Wed, 10 Jul 2013 18:40:23 -0600
> From: antoniolocandro 
> To: lar...@dakotacarto.com, madman...@gmail.com
> Cc: qgis-developer@lists.osgeo.org
> Subject: Re: [Qgis-developer] Toolbar and Panel defaults
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"
> 
> Could we add the possibility to close toolbars by undocking them and
> hitting an x in the window
> 
> I prefer the right for navigation than left
> 
> 
> 
> 
> > Sent from Samsung tabletLarry Shaffer  wrote:Hi
> > Nathan,
> > 
> > > On Wed, Jul 10, 2013 at 4:51 PM, Nathan Woodrow 
> > > wrote:
> > > Having the nav toolbar on the side would be ideal if you could dock it on
> > > the right side of the layers panel. ?I'm not a fan of having to go all the
> > > way over the layer panel to access the navigation tools.
> >
> > That's a very good point. What about the Navigation toolbar on the right,
> > with the Plugin toolbar filling the empty space at right on the first row
> > of horizontal toolbars?
> >
> > Here's my reasoning. Nav tools are quickly accessible, and when a new user
> > downloads/installs a plugin, there is already space to show it (assuming
> > that plugin loads a tool button into the Plugins toolbar). Then the user
> > can move toolbars to their liking.
> >
> > Any other ideas?
> >
> > [0] http://drive.dakotacarto.com/qgis/qgis_default_nav-tools-right.png
> > ?
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] SEXTANTE: R output?

[Alister Hood]

Hi guys,
Speaking of R, would it be worth adding some maintenance scripts? e.g. 

update.packages(checkBuilt=TRUE)

and even:

if(!require(installr)) { 
install.packages("installr"); require(installr)} #load / install+load installr
updateR()

I'm not much of an R guy - maybe there are other things too.

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

Re: [Qgis-developer] map rendering time much longer on windows than on ubuntu

[Alister Hood]

In the case that debug symbols are affecting speed, should setting this as an 
environment variable help?:
QGIS_DEBUG=-1

> Date: Tue, 09 Jul 2013 14:53:06 +0200
> From: Matthias Kuhn 
> To: Denis Rouzaud 
> Cc: qgis-dev 
> Subject: Re: [Qgis-developer] map rendering time much longer on
>   windows than on ubuntu
> Message-ID: <51dc07b2.6030...@gmx.ch>
> Content-Type: text/plain; charset=UTF-8
> 
> Apart from a dozen things influencing the rendering speed on a particular
> machine mostly related to the datasource (e.g. network/disk speed...), the
> binary itself can also be optimized by not including the debug symbols.
> 
> But to be accurate, one would need to do a more in-depth profiling of the
> problem...
> 
> -- Matthias
> 
> On Die 09 Jul 2013 14:38:24 CEST, Denis Rouzaud wrote:
> > Hi all,
> >
> > I noticed that QGIS renders much slower on windows than on ubuntu.
> >
> > This is the configuration:
> > Windows 7 64 bits
> > QGIS master from Osgeo4W
> > vs
> > Ubuntu 12.04 64its
> > QGIS compiled on computer
> >
> > The windows computer is more recent and powerful than ubuntu's one.
> > I have mainly PostGIS layers.
> >
> > Is it a know issue/problem/feature whatever?
> > Is there something I can do to speed up
> >
> > Thanks a lot,
> >
> > Denis 
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [Qgis-user] Final Logo Pick

[Alister Hood]

Just in case anyone was wondering, 5 means that you really like it, not that 
you really don't like it (the system here strips out some content on those 
pages, so I guess maybe everyone else can see some sort of explanation of that, 
but I can't).
And if your browser gives you a choice of 0-5 rather than 1-5, it looks like 0 
means you don't want to rate it, whereas 1 means that you really don't like it.

> Date: Tue, 14 May 2013 01:06:27 -0700
> From: Nathan Woodrow 
> To: Nyall Dawson 
> Cc: qgis-user ,
> "qgis-developer@lists.osgeo.org" ,
> "t...@wildintellect.com" 
> Subject: Re: [Qgis-user] [Qgis-developer] Final Logo Pick
> Message-ID: <5431422257135814391@unknownmsgid>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Vote on the second if your are only going to vote once. The second one
> has the picks from the first. The green background ones in the first
> have low votes so they are removed.
> 
> Sent from some fancy phone looking thingo
> > From: Nyall Dawson
> > Sent: 14/05/2013 5:56 PM
> > To: Nathan Woodrow
> > Cc: t...@wildintellect.com; qgis-user; qgis-developer@lists.osgeo.org
> > Subject: Re: [Qgis-developer] Final Logo Pick
> > >
> > > There are now two polls:
> > >
> > > http://99designs.com.au/logo-design/contests/qgis-needs-logo-210397/poll/aqu952
> > >
> > > http://99designs.com.au/logo-design/contests/qgis-needs-logo-210397/poll/ls2bf1
> > >
> > > I have to run the second poll in order even out the playing field as I
> > > missed some of Larry's in the pick and the ones I did where not a fair
> > > comparison.  As I can't not close a poll (I have requested it from the
> > > company but not word yet), or edit a poll (which is really dumb and makes
> > > this harder for me) I have to run two.
> > >
> > 
> > Should we be voting on both polls then? How does that work with the
> > logos which are on both polls?
> > 
> > Nyall
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Logo Update

[Alister Hood]

Hi again,
Have you guys that think #50 is more suitable for small icons actually tried 
shrinking them to small sizes?
#50 is fine as a large icon, but when you shrink it right down as a small icon, 
the triangle becomes so small that it pretty much disappears and you just have 
a bland circle icon.
When you shrink #336/#338 right down, the globe essentially disappears and you 
can't really tell that the hands are hands, but the overall design is so 
distinctive that it is still very easy to recognise.

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

Re: [Qgis-developer] Logo Update

[Alister Hood]

> Date: Tue, 30 Apr 2013 11:13:00 -0600
> From: Larry Shaffer 
> To: Radim Blazek 
> Cc: QGIS Developer List 
> Subject: Re: [Qgis-developer] Logo Update
> Message-ID:
>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> ...
> 
> Hmmm. I had never heard of Wassermann's hand, so that's just a coincidence.
> The hands represent dev's and user's hands, all working on the project
> together, but from different parts of the world and from different
> disciplines, which are represented by three elemental colors: brown
> (geology, landscaping, city planning, etc.), green (biology, forestry,
> etc.), blue (hydrology, oceanography, etc.).
> 
> Regards,
> 
> Larry

Neat, a logo with a nice story :)

Nathan, how is the final selection going to work?
Can we narrow the choice down first where there are a number of very similar 
versions by grouping them together as one (e.g. 338/336/340/335 or 
2/388/393/334/333/332/331)?

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

Re: [Qgis-developer] Images in legend

[Alister Hood]

Hi Paulo,

> Date: Tue, 23 Apr 2013 08:34:21 +0200
> From: Paolo Cavallini 
> To: qgis-developer 
> Subject: [Qgis-developer] Images in legend
> Message-ID: <51762b6d.3010...@faunalia.it>
> Content-Type: text/plain; charset=UTF-8
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi all.
> I have been submitted an interesting if weird problem. Sometimes it is 
> necessary to
> show in legend, especially for rasters but sometimes also for vectors, an 
> image that
> shows an extract of the map for better clarity. In other software, this is 
> done in an
> ugly fashion, by disaggregating the legend and inserting an image.
> I think we can do something better, by either defining among properties:
> * an image to use for the legend
> * a bounding box to extract the image from and put on the legend.
> The first option seems simpler, the second is probably better, as it can 
> update the
> legend if visualization properties change.
> Thoughts?
> All the best.
> - --
> Paolo Cavallini - Faunalia

Hi Paolo, I don't see how the second option is really much better, at least for 
vector layers.  If you specify the bounding box manually then there is still 
nothing to make sure it contains an appropriate part of the map.  e.g. for a 
layer using the classified renderer, if someone edits the attributes of the 
feature in the bounding box then it might be in a different class, and your 
legend would be wrong.

A better solution for vector layers might be this: provide a drop-down list of 
all the features (listed by fid) in the layer/class/rule, so the user can 
either just show the symbol by itself (the way it works currently), or select a 
feature from the drop-down list to display the part of the map containing that 
feature.  

This approach would still have limitations e.g. changes to the data or project 
might mean that the selected feature is hidden behind something else.  But if 
changes to the feature mean it is in a different class, then the legend would 
simply revert to either displaying just the symbol by itself, or displaying the 
next feature which is still in the class.

Note that if you implement something for this you can probably close 
http://hub.qgis.org/issues/4094.

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

Re: [Qgis-developer] [Qgis-user] [Qgis-psc] Logo

[Alister Hood]

Hi,

> Date: Sat, 20 Apr 2013 14:47:39 +1000
> From: Nathan Woodrow 
> To: Marco Bernasocchi 
> Cc: qgis-developer ,qgis-user
> 
> Subject: Re: [Qgis-developer] [Qgis-user]  [Qgis-psc] Logo
> Message-ID:
> 
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi all,
> 
> There is now another poll with some more designs:
> 
> http://99designs.com.au/logo-design/vote-9qwk3a
> 
> All polls can be found at:
> 
> http://99designs.com.au/logo-design/contests/qgis-needs-logo-210397/polls

In case you've added any more polls, note that this page is not visible without 
a logon.

> - Nathan

FWIW, I think that #336 is really good, but it was probably added to late to be 
really noticed.

A couple of people said they like the other variations of it, by I think the 
one which has the triangle on the Q in a different colour is no good because it 
isn't clear enough that it is a Q.  Even in #336 I guess it might not be clear 
enough, but the triangle does seem cool compared to a regular stroke on the Q...

Of course, I'm still not convinced it is better than the proposal here:
http://hub.qgis.org/issues/6688
;)
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [SoC] Applying for GSoC - GIS

[Alister Hood]

> Date: Tue, 26 Mar 2013 19:44:32 +0100
> From: Martin Landa 
> To: cavall...@faunalia.it
> Cc: qgis-dev , s...@lists.osgeo.org
> Subject: Re: [Qgis-developer] [SoC] Applying for GSoC - GIS
> Applications
> Message-ID:
> 
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Hi,
> 
> 2013/3/26 Paolo Cavallini :
> > See e.g.
> > http://hub.qgis.org/wiki/quantum-gis/Google_Summer_of_Code_2013
>
> btw, there are not so many ideas listed. I was just wondering if there
> is an another page (when I was showing this page to my students).

As well as the wiki pages of ideas from previous years, there are a few more 
ideas in the mailing list archives.  e.g. see
http://www.mail-archive.com/qgis-developer@lists.osgeo.org/msg07974.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Possible improvement | Actions on right click

[Alister Hood]

Hi guys, 

> Date: Thu, 14 Mar 2013 01:46:07 -0700 (PDT)
> From: R?gis Haubourg 
> To: qgis-developer@lists.osgeo.org
> Subject: Re: [Qgis-developer] Possible improvement | Actions on right
> click
> Message-ID: <1363250767637-5040280.p...@n6.nabble.com>
> Content-Type: text/plain; charset=UTF-8
>  
> Hi,
> +1 with Mathieu, actual action button needs to first choose an active layer
> and then to choose which action to execute on click.
>  
> Using right click might be intersting since it could be always available,
> whatever the tool selected.
> Another possibility is Mapinfo 's behaviour that we copied in Hotlink Plugin
> (in repository).
>  
> User has to choose hotlink tool (a thunder icon). On flyover, a tooltip show
> up with the list of all action titles located under the mouse cursor ( +
> display field info), for ALL layers.
> On click, a dropdown listbox shows up allowing to choose what action to
> execute.
>  
> I agree that starting having a right clic contextual menu would be better
> since user do not have to change his current tool. 

In this case I think rather than having a context menu dedicated just to layer 
actions, it might be better eventually to have a more general context menu, 
with actions in a submenu.

> The downside, it will
> give the habits of right clicking everywhere (composer too) and we should
> have a global discussion about contextual menus in QGIS, so that we have a
> consistent UI behaviour everywhere.

I think context menus would be good everywhere ;)

For most people when a right-click does anything different from opening a 
context menu they are surprised - assuming they even notice what it did.  If 
the right-click function is moved into a context menu then they will know what 
it did, even if they didn't read the manual. 

I guess getting rid of all direct right-click functions might upset some 
existing users, because an extra click will be required for the same function, 
but it will of course allow more functions to be added.

IIRC I think there is a recent proposal for context menus in the composer - in 
a ticket or pull request for paste to original coordinates.


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

Re: [Qgis-developer] New website

[Alister Hood]

> Date: Tue, 19 Feb 2013 11:02:49 +0100
> From: Paolo Cavallini 
> To: qgis-developer@lists.osgeo.org
> Subject: Re: [Qgis-developer] New website
> Message-ID: <51234dc9.5070...@faunalia.it>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Il 19/02/2013 10:28, Vincent Picavet ha scritto:
> >
> > Le mardi 19 f?vrier 2013 09:52:17, vinayan a ?crit :
> >> +1 the logo definitely needs a redesign..
> >
> >  +1 too.
> 
> I think we mostly agree with that, the issue is which route to take to find a 
> better
> one: contest or bid?

Another option could be to just use one of the existing proposals.
I don't think there were any negative comments when the one at 
http://hub.qgis.org/issues/6688 was proposed.  
It would be your "cleanup and revamp", rather than "a brand new one".

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

Re: [Qgis-developer] Opening a Shape file with out any browsing

[Alister Hood]

> Date: Mon, 21 Jan 2013 14:07:23 +0800 (SGT)
> From: PARDHU D 
> To: "Qgis-developer@lists.osgeo.org" 
> Subject: [Qgis-developer] Opening a Shape file with out any browsing
> Message-ID:
> <1358748443.58916.yahoomail...@web190501.mail.sg3.yahoo.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi to all,
> 
> Can anyone please send me the code for QGIS project (saved by the user) or 
> What is the code for QGIS when saving as a project. I just want
> to know the code for shape file (.shp file) in the QGIS project.
> Mainly I want code for adding shape file without any browsing. Can any
> one please send me a simple program for opening a shape file without
> browsing.
> 
> Regards,
> D Pardhu.

It is unclear whether you want to know about adding layers and saving project 
files programmatically, or about what information is saved in the project file 
for the layer.
If you want to know about the latter, just save a project file then open it 
with a text editor to see.

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

Re: [Qgis-developer] QGIS 1.8 Windows Standalone is not OK with spatialite versions (ECW tangent)

[Alister Hood]

> Date: Wed, 16 Jan 2013 23:05:23 +0800
> From: Ramon Andi?ach 
> To: qgis-developer 
> Subject: Re: [Qgis-developer] QGIS 1.8 Windows Standalone is not OK
> withspatialite versions (ECW tangent)
> Message-ID: <69b6fc13-1441-4ba1-9ce4-5b98254ad...@westnet.com.au>
> Content-Type: text/plain; charset=windows-1252
> 
> 
> On 16/01/2013, at 15:23 , Ted wrote:
> 
> > just minor correction in your letter, Chris is "Product" manager for ECW
> 
> Noted. I'll fix that before sending it off.
> 
> 
> > Just as I note, they have Read Only version of the SDK and also have few 
> > other editions;
> >
> > ERDAS ECW/JP2 SDK is offered as four different editions:
> >
> >   ? ERDAS ECW/JP2 SDK Server Read-Write provides tools to enable server 
> > applications to read ECW, ECWP, and JPEG2000 data, serve ECW and JPEG2000 
> > data, and compress images into the ECW and JPEG2000 data formats.
> >   ? ERDAS ECW/JP2 SDK Server Read-Only provides tools to enable 
> > end-user server applications to read ECW, ECWP and JPEG2000 data and serve 
> > ECW and JPEG2000 data via third-party server applications. For ESRI ArcGIS 
> > Server customers, please refer to ECW for ArcGIS Server.
> >   ? ERDAS ECW/JP2 SDK Desktop Read-Write provides tools to enable 
> > desktop applications to read ECW, ECWP and JPEG2000 and compress images 
> > into ECW and JPEG2000 data formats.
> >   ? ERDAS ECW/JP2 SDK Desktop Read-Only is a free product that provides 
> > tools to enable desktop applications to read ECW, ECWP and JPEG2000.
> >
> > Since this is a major shift from the 3.3 SDK which allowed WRITE function 
> > upto 500MB, we could use without much of a problem. After hexagon, there 
> > has been lot of changes and also the licensing of SDK.
> >
> > At the moment, for GDAL and well and general QGIS user, what we are looking 
> > at is, DESKTOP READ ONLY SDK where by users could use ECW files in QGIS.
> >
> > So, we need to be very specif about this.
> >
> > They will never allow GDAL or anyone else to use the library for ECW 
> > Serving function, without $. So, dont even bother to ask.
> See notes below.
> 
> > So, with GDAL, we should make a point to mark ECW as Read only format.
> No. Currently that is only the situation for *windows* users, as everyone 
> else is still using the 3.3 SDK, which as you note allows writing.

Of course, on Windows gdal ecw can be used for a server or with write support 
if you do want to spend the money.
 
> 1. I thought it was reasonably clear that I was talking about the Desktop 
> Read-Only SDK. If it's not, please say so.
> I haven't made reference to any other of the licences in the explanation or 
> the questions.
> 
> 2. If I understand from Paolo and previously J?rgen, the really big sticking 
> point is that it is possible to install a QGIS server on a GDAL with the 
> desktop SDK plugged in. Depending on who's responsible for the correct use of 
> the SDK defines the ease of which the ECW-plugin can be put back into 
> service. So the clarifying questions 3 and 4 are in that sense the important 
> ones.
> 
> If the responsible party is people like me (the user end) then a big fat 
> warning as you suggest will probably do. Have to see what they say.
> If the responsible party is the developer end, then the problem is *much* 
> more difficult, as there would need to be ways built in to make sure that the 
> desktop only part was *not* contravened. (As a User I can see this is 
> complicated. Money may help, but it's also an ethical thing too.)
> 
> 3. In light of the above I felt that the explanation leading into the 
> questions was important to give a sense of where the questions were coming 
> from.
> 
> Questions 1 and 2, we probably know the answers to, but it would be good to 
> see if we can get straight answers on them.
> Questions 3 and 4 are the important ones.
> Questions 5 and 6 are requests for information.[1]
> 
> 5. I've not even asked about the requirement to support both ECW and ECWP... 
> This is pretty much a secondary hurdle to me.

Note that GDAL does support ECWP, so I think even if the QGIS gui does not 
provide a way to load it, that should be possible from the Python console or 
using a GDAL "service description" XML file or a .vrt file.  But I haven't 
tested as I've never come across ecwp in the wild...
 
> 6. I'm was about to head for bed so apologies if this is not as sensible as 
> I'd like. I thought having my thoughts (such as they are) out while most 
> others are awake would be worth it.
> 
> -ramon.
> [1] Current version (with revisions based on Alister's earlier comments) is 
> now here: 
> https://www.dropbox.com/s/b5wclxeheeh4act/QuestionsForIntergraph2012i16
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 1.8 Windows Standalone is not OK with spatialite versions (ECW tangent)

[Alister Hood]

> Date: Tue, 15 Jan 2013 18:43:10 +0800
> From: Ramon Andi?ach 
> To: qgis-developer 
> Subject: Re: [Qgis-developer] QGIS 1.8 Windows Standalone is not OK
> withspatialite versions (ECW tangent)
> Message-ID: <2d60c7de-a02a-499e-a834-775dd67ad...@westnet.com.au>
> Content-Type: text/plain; charset=iso-8859-1
> 
> 
> On 15/01/2013, at 15:27 , Paolo Cavallini wrote:
> 
> > Il 15/01/2013 00:28, Ramon Andi?ach ha scritto:
> >> Ok. I'll go back through the licensing documentation in the next few days.
> >>
> >> If I'm doing this I have some questions. (J?rgen, Paolo?)
> >> What would appropriate questions would be? Paolo's comment below seems 
> >> really open to me.
> >>  (Neither developer or lawyer, so would appreciate comment).
> >> What was the previous arrangement?
> >
> > AFAICT, the SDK can be used for "dektop programs", not for servers. The 
> > issue is: if
> > we compile GDAL with non-free SDK, this can be used both for the desktop 
> > and for the
> > server (mapserver, QGSI server, etc.). It is unclear if the responsibility 
> > lies with
> > the user (so a warning "use only for desktop" is enough) of with the 
> > developer (in
> > this case, we cannot distribute it).
> > If someone has a better understanding, please let us know.
> > All the best.
> 
> Thanks Paolo, much appreciated.
> 
> I've drafted a letter, but I'd like some feed back before I send it off.[1]
> 
> Along the lines of:
> Does it make sense?
> Am I understanding correctly?
> Does it cover the questions that need asking?
> and,
> I'm not misrepresenting any of the QGIS or OSGeo camps and in any way?
> 
> Particularly, if Paolo, J?rgen and Frank had anything to say on the note that 
> would be appreciated.
> 
> 
> -ramon.
> 
> [1] https://www.dropbox.com/s/dwq8qzc6yvh27jx/QuestionsForIntergraph2012i15
> (I can open the folder up if people have big notes, that would be better left 
> there)

In relation to the last question in the letter, they are/were working on an 
updated Linux version:
http://field-guide.blogspot.co.nz/2011/07/erdas-ecwjp2-sdk-for-linux.html
http://field-guide.blogspot.co.nz/2012_05_01_archive.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Get rid of Shapefiles ! Go SpatiaLite !

[Alister Hood]

> Date: Mon, 26 Nov 2012 15:35:24 +
> From: Barry Rowlingson 
> ...
> >
> > I am very frustrated by the limitations of the Shapefile format, and much
> > more by the quasi obligation to use it as the default vector format in QGIS.
> > I mean for non power users who do not use PostGIS or spatialite.
> 
>  Why is spatialite seen as a "power user" option when ESRI users have
> been using something similar for years? Its just a file, you connect
> to it, you add spatial data to it.

Well, I think it IS a "power user" option as long as things output only to 
shapefile, after which the user needs to perform an extra step to import to 
spatialite.  This discussion on abstraction is good to see.

Users won't perform the extra step unless they have a motivation to do so.  
Personally I have only used spatialite a couple of times, when I needed to 
perform special queries.  And these queries are also very much for "power 
users" - the user isn't confronted by any documentation telling them about the 
cool stuff they can do (and how to do it), so people are most likely to do it 
only after googling to solve a particular problem.

If you don't need to run a special query or something, does spatialite have 
major benefits?  Do these need some publicity?
Things like the length of field names seem pretty minor to me...

And maybe this is a little off topic, but does anyone else have trouble with 
the implementation of spatialite in qgis?
In my experience it is very slow (takes 6 hours to save as or import a layer to 
spatialite, when ogr2ogr takes less than 5 minutes), and tends to be 
accompanied by a series of frightening error/warning messages.

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

Re: [Qgis-developer] Merging of incompatible changes

[Alister Hood]

> Date: Thu, 25 Oct 2012 07:48:30 +0900
> From: Paolo Cavallini 
> To: qgis-developer@lists.osgeo.org
> Subject: Re: [Qgis-developer] Merging of incompatible changes
> Message-ID: <5088703e.3070...@faunalia.it>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Il 25/10/2012 05:39, Pirmin Kalberer ha scritto:
> > We did decide filling the missing gaps to fully replace old
> > symbology and old labelling (Paolo: Kickstarter pledge on the way?) and
> > polishing the many new features already integrated.
> Sorry, no progress on this. I've asked for some feedback and help, got
> none. Very little time now, planning to do it ASAP. Any help welcome.
> > plugins. It will take years to bring them all in sync with QGIS again.
> I understand both Pirmin and Martin concerns. I think seriously breaking
> the API and all the plugins will be good *if* we have a serious plan on
> how to migrate the plugins. At this stage, we cannot afford releasing a
> 2.0 without plugins, as nobody will use it, and we'll get stuck in the
> middle of the transition. This had proved to be a major problem for many
> software, sometimes effectively killing it, and we should really
> seriously avoid them.
> I think it is realistic, on the basis of the response to the request to
> move plugins to the new infrastructure, to assume that many developers
> will not do the migration in time: are we willing and capable of
> upgrading them ourselves, or do we plan to leave them as such?

When is "on time"?
Is it "before 2.0 is released"?
When people use software like Firefox they are accustomed to a lot of 
extensions becoming "incompatible" if they upgrade to a new version when it is 
released.  In that case there is seldom any real benefit associated with the 
upgrade.  But the threading is a major performance improvement, which is worth 
breaking compatibility isn't it?  And people have been eagerly anticipating it 
for years already...

Would you assume that most of those developers who have migrated their plugins 
to the new infrastructure will also update them for API changes?
Wouldn't that mean there isn't much of a problem, because whichever plugins 
won't be updated aren't available to users in the repository, anyway? ;)

Or has someone now migrated a significant number of unmaintained plugins to the 
new infrastructure?  If so, how many?
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] User profiles

[Alister Hood]

> Date: Wed, 24 Oct 2012 09:56:47 +0700
> From: Marco Bernasocchi 
> To: qgis-developer@lists.osgeo.org
> Subject: Re: [Qgis-developer] User profiles
> Message-ID: <508758ef.4030...@bernawebdesign.ch>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On 10/24/2012 09:53 AM, Alister Hood wrote:
> > Hi guys,
> >
> >> Date: Tue, 23 Oct 2012 18:43:50 +0200
> >> From: Martin Dobias 
> >> To: Paolo Cavallini 
> >> Cc: qgis-developer 
> >> Subject: Re: [Qgis-developer] User profiles
> >> Message-ID:
> >> 
> >> 
> >> Content-Type: text/plain; charset=ISO-8859-1
> >>
> >> Hi Paolo
> >>
> >> On Tue, Oct 23, 2012 at 2:56 PM, Paolo Cavallini  
> >> wrote:
> >>> Hi all.
> >>> The discussion of this evening brought a nice idea: since we have many
> >>> different types of users, whi not having a "first usage wizard" that
> >>> simply asks the user which profile (s)he prefers, and then starts QGIS
> >>> with only the needed menus and buttons activated? The profiles can be
> >>> easily produced via the customization menu, so this seems trivial to
> >>> implement, and can greatly help first-time users and special interest
> >>> groups.
> >>> Of course we have to have a prominent menu to re-run the wizard, and
> >>> change the choice.
> >>> Opinions?
> >>
> >> I am just afraid that with such profiles the users may forget after a
> >> while they have chosen a "first-time user" profile that disables a lot
> >> of functionality and then users will ask/complain about missing
> >> features...?
> >
> > Yes, I can see why you might want to offer some default "profiles" to 
> > control which toolbars and panels are visible, but I don't think it is a 
> > good idea to use the customisation feature to hide any functionality.
> >
> can you elaborate on why?

Here is my train of thought:

If there was a system of different profiles, I imagine they should be task 
oriented, e.g. "raster analysis" or "hydrological modelling" (rather than 
"view", "edit" and "analyse" or "beginner", "expert" and "master of the known 
universe").

If the profiles used the "customisation" mechanism, they would not just control 
which toolbars and panels are on or off by default, they would control which 
toolbars are actually visible in the right-click menu and able to be turned on 
or off there.
As well as hiding toolbars and panels, it is natural that specific menu entries 
and toolbar buttons would be hidden in each profile, and when a user needed a 
specific feature they would need to switch through several profiles looking to 
see if it existed, or alternatively look for it in the customisation dialog and 
enable it there (which would kind of defeat the purpose of the profiles).  
Essentially the hidden features would be a lot less discoverable.

How would the default profiles work with user customisations (including the 
user simply turning a toolbar on or off)?  When a user switches to a different 
profile, would their own customisations be automatically saved to the first 
profile?  Would they be prompted to save the changes to a new custom profile?  
Is this complication really necessary?

If the menus are organised into a nice logical hierarchy (as they should be), 
shouldn't it be easy for people to find the features they need, and shouldn't 
there be no need to hide features to protect people from them, because people 
naturally won't go into the parts of the menu that contain the features they 
don't need?

Does QGIS really need a system of standard profiles?  Will that actually 
address the things that are bothering people?  Or are other fixes or 
improvements required to address these?
e.g.:
- make the "customisation" feature actually capable of hiding buttons in the 
plugin toolbar.
- make "customisations" apply without a restart (I presume this already works 
on systems, otherwise I don't know what the "apply" button would be for).
- make it possible for users to create extra toolbars, and even drag-and-drop 
buttons between different toolbars.
- gui cleanups like the famous unified add layer dialog.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] User profiles

[Alister Hood]

Hi guys,

> Date: Tue, 23 Oct 2012 18:43:50 +0200
> From: Martin Dobias 
> To: Paolo Cavallini 
> Cc: qgis-developer 
> Subject: Re: [Qgis-developer] User profiles
> Message-ID:
> 
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Hi Paolo
> 
> On Tue, Oct 23, 2012 at 2:56 PM, Paolo Cavallini  
> wrote:
> > Hi all.
> > The discussion of this evening brought a nice idea: since we have many
> > different types of users, whi not having a "first usage wizard" that
> > simply asks the user which profile (s)he prefers, and then starts QGIS
> > with only the needed menus and buttons activated? The profiles can be
> > easily produced via the customization menu, so this seems trivial to
> > implement, and can greatly help first-time users and special interest
> > groups.
> > Of course we have to have a prominent menu to re-run the wizard, and
> > change the choice.
> > Opinions?
> 
> I am just afraid that with such profiles the users may forget after a
> while they have chosen a "first-time user" profile that disables a lot
> of functionality and then users will ask/complain about missing
> features...?

Yes, I can see why you might want to offer some default "profiles" to control 
which toolbars and panels are visible, but I don't think it is a good idea to 
use the customisation feature to hide any functionality.

> btw. Personally I'm quite intimidated by the amount of toolbars and
> icons that QGIS shows by default (i.e. first run). I think if we could
> cut that down to a one line of icons, that will be a good start.

Me too.  I'm more of an enthusiast than a frequent user, but I imagine the 
features most users would need to use frequently are on the "navigation", 
"digitizing" and "attributes" toolbars, so you would probably get away with 
showing only these by default.

I'm not too sure about the panels - maybe just "layers"?  Or "layers" and 
"overview"?

I think there might be a ticket with a discussion of this, too... or maybe 
there was just a previous discussion on the mailing list.


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

Re: [Qgis-developer] Saving expressions

[Alister Hood]

Hi guys,
Personally I think saving expressions for every layer is unnecessarily 
complicated.  Have you thought of just having a drop-down list of recently used 
expressions, and the ability to "pin" your favourite expressions to the list?  
Do people really need expressions to be saved alongside the project/layer?
How are you thinking about doing the gui?  Even if you do implement "program" 
and "layer" lists of expressions, you could do something like that for the gui: 
display a list of recently used expressions grouped under "this layer" and 
"other layers", and with the ability to "pin" favourite expressions.

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

Re: [Qgis-developer] how can i use my own map tiles in qgis?

[Alister Hood]

Hi Leena,
You never confirmed why you need to do this.  Did you ever try 
"Raster>Miscellaneous>Build Virtual Raster (catalog)"?

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

Re: [Qgis-developer] Default typeface to package with app

[Alister Hood]

Hi guys,
Including a standard font has obvious benefits for testing labelling etc, but 
I'm wondering if the benefits of using it for the gui aren't wishful thinking.

I think it is essential to allow the user to be able to control the font size 
(preferably by obeying the system font settings), as some screens are at least 
twice the DPI of other screens, and some people need larger fonts due to eye 
problems (personally, I usually find applications that specify their font 
offensive because it is too _big_, and typically they also either force blurry 
antialiased rendering, or a font which looks awful with antialiasing and 
cleartype disabled).

If someone was using a larger font than the "standard", would you say, "sorry, 
that's not a bug, use the standard font"?
Surely it is better to focus on accessibility, making a gui that can cope with 
different font settings?
Or am I missing something?  Would you design the gui to make sure it works with 
the standard font at multiple sizes?

Note: unlike other QT applications, at least on Windows QGIS currently ignores 
the system font size (and there is no qtconfig available on Windows)... I would 
consider this to be a bug.

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

Re: [Qgis-developer] What is the purpose of turning of 'on the fly' crs transformation?

[Alister Hood]

> Date: Thu, 6 Sep 2012 00:14:04 -0700 (PDT)
> From: Magnus Homann 
> To: qgis-developer@lists.osgeo.org
> Subject: [Qgis-developer] What is the purpose of turning of 'on the
>   fly' crstransformation?
> Message-ID: <1346915644405-5000110.p...@n6.nabble.com>
> Content-Type: text/plain; charset=us-ascii
> 
> Since 0.7 (?) we have included OTF transformation. In the beginning, the
> code
> was a bit buggy :-), and I believe that was one of the main reason for
> turning it off. Now, it's more stable. So, hwat is the reason for being
> able
> to turn it off now?

Sorry for the late reply, but I find it useful to see quickly whether all my 
layers have the same CRS or not (which is useful in cases where you want to use 
a tool where the layers are required to be in the same CRS).
 
> 1) Some use-cases handles 'raw' data where a CRS is not meaningful (or
> maybe
> unknown even).
> 2) To skip the OTF code for stability.
> 3) To skip the OTF code for speed.
> 
> Measruement tools uses OTF code to be able to calculate on an ellipsoid.
> Currently, when OTF is off, we don't allow that but usees planimetric
> calculation only. Is this correct do you think?
> 
> Magnus

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

Re: [Qgis-developer] implement data provider in python?

[Alister Hood]

Hi,
Didn't someone say they were working on an on-the-fly graticule provider, which 
is similar to your use case (but I doubt it involved Python)?

Alister


> Date: Wed, 29 Aug 2012 16:53:39 +0200
> From: "G. Allegri" 
> To: Etienne Tourigny 
> Cc: qgis-developer 
> Subject: Re: [Qgis-developer] implement data provider in python?
> Message-ID:
>   
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Thanks Etienne, I didn't know it.
> Yet it doesn't do exactly what I was thinking about, beacuse I suppose
> that the plugin layer cannot be managed as a true layer. AFAICS it has to
> implement the rendering operations, which set the style, etc.
> Having a "plugin provider" would require only to write the code to provide
> the data, leaving the rest of the management (styling, rendering, etc.) to
> Qgis.
> 
> giovanni
> 
> 2012/8/29 Etienne Tourigny 
> 
> > I am not quite sure how it works, and there are few details available,
> > maybe someone who knows how it works can provide some insight?
> >
> > The openlayer plugin is implemented as a plugin layer. It doesn't
> > interact with other layers, but seems to do what you are talking about
> > (gets queried on every pan/zoom/etc to retrieve the update data).
> > Have a look at the code.
> >
> > API stuff:
> > http://qgis.org/api/classQgsPluginLayer.html
> > http://hub.qgis.org/issues/2392
> >
> > On Wed, Aug 29, 2012 at 11:04 AM, G. Allegri  wrote:
> > >> you might be able to achieve that using "plugin layers" which are
> > >> map layers that can be created and updated by plugins
> > >
> > >
> > > What do you mean Etienne?
> > > How can I serve a layer, dynamically, through a python plugin? I
> > > don't
> > want
> > > to have a plugin that creates a memory layer, but that gets queried
> > > on
> > every
> > > pan/zoom/etc to retrieve the update data.
> > >
> > > giovanni
> > >
> > >>
> > >>
> > >> > The other is having the possibility to bridge, easily, any kind
> > >> > of
> > data
> > >> > source, using python as an adapter.
> > >> >
> > >> > giovanni
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > 2012/8/29 Barry Rowlingson 
> > >> >>
> > >> >> I have a vague memory that the python data provider idea was
> > >> >> considered a while ago. I was thinking about how one could get
> > >> >> direct access from Qgis to R spatial data sets stored in R's
> binary files.
> > >> >> One method would have been to write a provider in python that
> > >> >> used
> > Rpy
> > >> >> to bridge to R, but wasn't possible because you can't write data
> > >> >> providers in Python. It could be done in C by linking to R's C
> > >> >> library, but at that point I lost interest and used a looser
> > >> >> coupling to get my R data into Qgis.
> > >> >>
> > >> >> The argument then went that if the provider was designed to
> > >> >> access a file it would be a better idea to write a GDAL/OGR
> > >> >> driver, then even people outside QGIS could use it. Obviously
> > >> >> that would have to be C/C++ though.
> > >> >>
> > >> >> And then I think everyone got bored and went back to doing things.
> > >> >>
> > >> >> Do you have a specific use-case?
> > >> >>
> > >> >> On Wed, Aug 29, 2012 at 8:01 AM, G. Allegri 
> > wrote:
> > >> >> > Anybody interested in developing the concept and evaluating
> > >> >> > its feasibility?
> > >> >> > I'm considering the possibility to sponsor it.
> > >> >> >
> > >> >> > giovanni
> > >> >> >
> > >> >> > Sent from Nexus
> > >> >> >
> > >> >> > Il giorno 28/ago/2012 00:11, "G. Allegri" 
> > >> >> > ha
> > >> >> > scritto:
> > >> >> >>
> > >> >> >> AFAIK it isn't possible to register a python script as a
> > >> >> >> dataprovider.
> > >> >> >> Maybe it sounds odd, but I think it would interesting if we
> > >> >> >> could have it.
> > >> >> >> Has it been ever considered? How hard would it be to implement
> it?
> > >> >> >>
> > >> >> >> Giovanni
> > >> >> >>
> > >> >> >> Sent from Nexus
> > >> >
> > >> >
> > >> >
> > >> > ___
> > >> > Qgis-developer mailing list
> > >> > Qgis-developer@lists.osgeo.org
> > >> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
> > >> >
> > >
> > >
> >
> -- next part --
> An HTML attachment was scrubbed...
> URL:  developer/attachments/20120829/14b512b8/attachment.html>
> 
> --
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> 
> End of Qgis-developer Digest, Vol 82, Issue 88
> **
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] New Plugin - Edit Any Layer

[Alister Hood]

Hi,

> Date: Wed, 1 Aug 2012 16:39:01 +0100
> From: Rob Nickerson 
> To: qgis-developer@lists.osgeo.org
> Subject: [Qgis-developer] New Plugin - Edit Any Layer
> Message-ID:
> 
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi All,
> 
> It seemed a little bit odd to me that QGIS is able to open many file types
> but you can only edit a couple of them. Being new to the world of GIS and
> therefore not understanding any of its history, this seemed as odd as
> photoshop being able to open but not edit jpeg files!
> 
> In part of my work looking at adapting fTools / SEXTANTE to write to memory
> layer / any ogr format, I have created a standalone plugin that converts
> any vector layer to a memory layer (and therefore allows you to edit the
> layer). This plugin is hosted at [1], if you like I will move it to a more
> permanent location.
> 
> Notes:
> 
> * Filters for just vector layers (but could be further filtered to vector
> layers that cannot be edited in their current format).

Please don't restrict it like that.  It is useful to be able to make a memory 
layer copy of even a layer that is writeable.  You might even consider renaming 
it to reflect that - "Copy as memory layer" perhaps?

What would be useful is an option to only copy the selected features.  And it 
should work even with no selected features - this would provide a quick way to 
create an empty memory layer with the same attribute columns.

> * No progress bar at the moment (at 1000's of features the plugin can take
> a little while so will add a progress bar at a later date).
> 
> [1] http://ubuntuone.com/3Zl1ojo3ZMUJxMqj2kcZaX
> 
> Regards,
> Rob

Nice plugin - good work!
Alister
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Clarifying access to non geographical datas

[Alister Hood]

> Date: Tue, 10 Jul 2012 10:32:03 +0100
> From: Giovanni Manghi 
> To: haubourg 
> Cc: qgis-developer@lists.osgeo.org
> Subject: Re: [Qgis-developer] Clarifying access to non geographical
> datas
> Message-ID: <1341912723.2442.25.camel@sibirica>
> Content-Type: text/plain; charset="UTF-8"
> 
> On Fri, 2012-07-06 at 07:31 -0700, haubourg wrote:
> > Hi all, i would like to have your feedbacks on that point, before
> > asking new features.
> 
> I agree, an explicit "add table" button should be added.
> 
> cheers
> 
> -- Giovanni --

If "add table" would actually use the same dialogue as "Add Vector Layer", 
would it not be better just to rename that to "Add vector layer or table"?
Personally I wouldn't have expected most people to use the toolbar, but the 
same applies to the menu entries...

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

Re: [Qgis-developer] Releasing 1.8

[Alister Hood]

It is not a regression or anything, but is there any chance someone could check 
this?:
http://hub.qgis.org/issues/3330

It is a one line fix for a long-standing bug.

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

Re: [Qgis-developer] String freeze and call for final translation updates

[Alister Hood]

Hi again,

> > From: Giovanni Manghi [mailto:giovanni.man...@faunalia.pt]
> > Sent: Monday, 28 May 2012 11:50 a.m.
> > To: Alister Hood
> > Cc: qgis-developer@lists.osgeo.org
> > Subject: Re: [Qgis-developer] String freeze and call for final translation
> > updates
> > 
> > Hi,
> > 
> > > Maybe you wouldn't technically classify it as a regression, but if I
> > > remember correctly, the list of "Recently used" CRSs is a new feature in
> > 1.8, and a fairly serious bug has been introduced with it:
> > > http://hub.qgis.org/issues/5030#note-5
> > 
> > 
> > it is just my opinion, but I don't see this as a blocker but certainly
> > something to be fixed.
> > 
> > If you enter the "set layer crs" dialog is because you want to change the
> > CRS to the layer. 

This is not a safe assumption.

> > If the crs you need is not listed in the "recently used
> > CRSs" then you have the filter. If you click "cancel" the CRS is not
> > changed regardless what was selected.

I've replied on the tracker if anyone wants to follow it.


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

Re: [Qgis-developer] String freeze and call for final translation updates

[Alister Hood]

Hi,
Sorry I'm late to the party,

> Date: Sun, 27 May 2012 19:48:09 +0100
> From: Giovanni Manghi 
> To: Tim Sutton 
> Cc: qgis-developer 
> Subject: Re: [Qgis-developer] String freeze and call for final
>   translation updates
> Message-ID: <1338144489.2370.28.camel@sibirica>
> Content-Type: text/plain; charset="UTF-8"
> 
> 
> > There is currently one blocker left in the queue[1] before we can
> > release 1.8. At this time we would like to declare a total string
> > freeze on QGIS 1.8 and call for final translations. Assuming the last
> > bug gets squashed this week,
> 
> I confirm that there are not other known regressions.
> 
> cheers
> 
> -- Giovanni --

Maybe you wouldn't technically classify it as a regression, but if I remember 
correctly, the list of "Recently used" CRSs is a new feature in 1.8, and a 
fairly serious bug has been introduced with it:
http://hub.qgis.org/issues/5030#note-5

If it came down to the choice, personally I think it would be better to revert 
the new feature than to leave it in with the bug.

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

RE: [Qgis-developer] show grid on map canvas (similiar to grid used in composer) - strategy?

[Alister Hood]

Hi again,

> On Fri, May 11, 2012 at 10:40 AM, Etienne Tourigny 
 wrote:
> 
> Hi all
> 
> On Thu, May 10, 2012 at 5:39 PM, Martin Dobias  wrote:
> > Hi
> >
> > On Thu, May 10, 2012 at 2:06 PM, Nathan Woodrow  wrote:
> >> I think if QgsPluginLayer is a usable option that would be the way to go, 
> >> or
> >> maybe  QgsVectorLayer  but I suspect that you will need a provider for
> >> that.
> >
> > I would suggest _not_ to create another provider for grids (for use as
> > a vector layer). A grid is not really made of vector features, and
> > lots of vector operations do not make much sense for grid. An

Yes, I think most people would never use vector operations on a grid.  And I 
guess the digitising tools would be disabled for these layers.  But people do 
treat grids as features for geoprocessing,.

> > interesting approach might be to use QgsPluginLayer class, but IMHO a
> > grid is not even a layer... e.g. does it make any sense to draw some
> > other layers on top of a grid?

Certainly not usually, at least for printing, although I can imagine using a 
grid of alternating filled gray and white squares under the map layers, rather 
than grid lines over the map layers.  
I can also imagine if someone was working with point and line layers and 
unfilled polygon styles they might move these layers above the grid to make it 
easier to see them.  
Anyway, it would certainly make sense in some cases to have more than one grid 
"layer", to be able to symbolise them differently (which implies being able to 
control which one of them is above another) and turn them on and off 
independently.  Creating them as layers would make this simple.

> I guess it makes more sense to draw the grid on top - are there any
> uses to draw the grid below the layers? In any case, a simple
> (top/bottom) selector would suffice.

I doubt there are many cases when somebody would want grids below the layers, 
but I wouldn't rule it out entirely.
But I do think people would want grids below feature labels and diagrams (other 
map decorations are above these), and below map annotations (other map 
decorations are below these, although I think that they probably shouldn't be).

> > For me a grid is a good candidate to be implemented as another type of
> > decoration (currently there is north arrow, scale bar and copyright
> > label). A decoration is drawn on top of the map when map rendering has
> > finished. And symbology can still be applied when drawing grid as a
> > decoration.
> 
> Hmm... symbology applied to what?

See below.

> Nathan's suggestion to make it a layer to be able to style it makes
> sense. Any way we can use the symbology interface on a map decoration?

I think that's exectly what Martin is saying can be done.

> Can we re-use existing widgets for this, or just a waste or time
> instead of designing a new widget?

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

[Qgis-developer] show grid on map canvas (similiar to grid used in composer) - strategy?

[Alister Hood]

> Date: Wed, 9 May 2012 18:00:07 -0300
> From: Etienne Tourigny 
> Subject: [Qgis-developer] show grid on map canvas (similiar to grid
> used in composer) - strategy?
> To: qgis-developer 
> Message-ID:
> 
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Hi all,
> 
> I would like to add support to draw a grid on the map canvas, in a way
> similar to what is done in the map composer (although perhaps without
> the annotations on the borders).
> 
> What should be the approach used?
> 
> 1) plugin or core?
> 2) rubberbands or basic plot functions triggered after mapCanvas update?
> 
> I think both drawing strategies are possible using a plugin.
> 
> It would be best to write in the core, assuming there is sufficient
> interest in this, but it will take time to trickle down to the stable
> version (an argument for making it a plugin).
> 
> I know the current workaround is to create a vector grid with ftools,
> but that is a little clunky.
> 
> Any thoughts?
> Etienne

Hi,
I'm not a developer, so this might be a crazy and unnecessary idea, but would 
it be feasible to create a graticule _provider_?

This approach would mean that like grids created with ftools, the grid would be 
created as a layer, but it wouldn't be file based and its extents would 
automatically update.

Unlike the approach used in the composer, this would mean:
- digitising tools could snap to the grid lines.
- the identify tool could identify the grid lines.
- the layer could be used for analysis (e.g. you might want to use it to split 
vector layers).
- symbology and feature labelling could work just like other vector layers.

If this was to actually replace the grids in the composer, some improvements to 
feature labelling would be needed.  Some of these would probably be good to 
have anyway, e.g. an option to label both ends of a line, and an option to 
align labels horizontally or vertically on the page, rather than N-S or E-W.  I 
guess the difficult one would be providing a way to display labels outside the 
map frame...

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

[Qgis-developer] RE: [Qgis-user] Questions about vector connections to ArcSDE

[Alister Hood]

Hi Stefan,
1. I made no progress with the problem of connecting to a remote SDE server (as 
opposed to a local server, which I don't have access to).
2. I don't know whether Marty made any progress with read-write access and the 
other issues.
3. After I sent that message, Marica also posted to the forum thread with 
another question which was not answered.
No, I haven't tried with SDE10.x, either.  Please let us know what success you 
have though :)

Alister

-Original Message-
From: Stefan Keller [mailto:sfkel...@gmail.com] 
Sent: Saturday, 28 April 2012 11:28 a.m.
To: Alister Hood
Cc: qgis-u...@lists.osgeo.org; qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-user] Questions about vector connections to ArcSDE

Hi Alister, hi QGIS user and QGIS dev

2011/9/26 Alister Hood :
> Hi,
> We've been trying to troubleshoot connection to ArcSDE, in the forum 
> at
> http://forum.qgis.org/viewtopic.php?f=3&t=8835&p=21599 and 
> subsequently via PM.  If anyone has some experience with this, we're 
> wondering a few
> things:
> 1) If you have write permissions (i.e. the right username and 
> password), and you connect via "Add vector layer->Database->ESRI 
> ArcSDE", should the connection be read-write?  Marty is finding that it is 
> read-only.
> 2) Can you connect to a remote ArcSDE server via "Add vector
> layer->Database->ESRI ArcSDE"?
> 3) If you are connecting to a remote ArcSDE server, either this way, 
> or using a VRT, what do you enter as the "host"?  Is it the url of the 
> server, without any http etc?
> 4) Using a VRT, Marty is finding that it appears to be read-write 
> (although the "delete features" button is disabled), but when he stops 
> editing nothing is actually saved back to the SDE.  Does it work for 
> anybody else?
> 5) Using a VRT, Marty is finding that some of the attribute fields 
> show up with NULL values, but connecting via "Add vector
> layer->Database->ESRI ArcSDE" the correct values are shown.  Does
> anybody have an idea about this?
>
> Thanks,
> Alister
> ___
> Qgis-user mailing list

Was there an outcome of these observations and questions?

Has anybody tested it with ArcSDE 10.x (especially under Windows)?

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

Re: [Qgis-developer] GSoC deadline (was: Working on Symbology Improvement for the GSOC)

[Alister Hood]

Hi,
I realise the gui code would be pretty much rewritten, but do you think it 
would it be worth adding a first step to review and apply any existing patches 
for missing functionality? e.g.
http://hub.qgis.org/issues/3430


> Date: Wed, 4 Apr 2012 21:25:44 +0530
> From: "arunthe...@gmail.com" 
> Subject: Re: [Qgis-developer] GSoC deadline (was: Working on Symbology
> Improvement for the GSOC)
> To: cavall...@faunalia.it
> Cc: qgis-developer@lists.osgeo.org
> Message-ID:
> 
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Completed the Proposal in all aspects. Open to review.
> 
> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/tecoholic/1
> 
> Thank you.___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Re: import proprietary code inside a python plugin

[Alister Hood]

> Date: Tue, 27 Mar 2012 11:06:19 +0200
> From: Vincent Picavet 
> Subject: Re: [Qgis-developer] Re: import proprietary code inside a python 
> plugin
> 
> Hi,
> 
> > In osgeo4w the gdal-ecw DLLs are released binary compiled. I never needed
> > to compile them by myself. Are you saying that osgeo4w is doing something
> > incorrect?

I guess with OSGeo4W you can install just GDAL (and gdal-ecw) and it will be 
under the MIT license.
If you install GDAL and QGIS they must be under the GPL.
So in theory you shouldn't be able to install all three?  It doesn't really 
seem to work... perhaps this demonstrates an inherent problem with the whole 
system of software licensing.

> The gdal/ecw case is particularly complex, as the ECW licence changes
> regularly and is some kind of opensource but not really.

The "new" read-only ECW dlls that are distributed in the QGIS Windows installer 
are not at all open source.  Paolo said something not long ago about needing to 
talk to Erdas to clarify the situation, as apparently at one stage they granted 
special permission to redistribute them with QGIS.  But I'm pretty sure after 
this conversation that they are *not* redistributable with QGIS.  The license 
on the "new" dlls has changed at least once, but I don't see how it could 
affect this conversation, as it has never been GPL compatible.

The "old" read-write ECW libs that are typically used on linux can supposedly 
be distributed with GPL software, so I think it would make sense to use them 
also on Windows (especially since they are read-write).
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Re: import proprietary code inside a python plugin

[Alister Hood]

> Message: 4
> Date: Mon, 26 Mar 2012 13:33:54 +0200
> From: Tim Sutton 
> 
> > I personnaly consider that libraries should not be under a GPL licence
> but a
> > LGPL one, which keeps the opensource aspect while facilitating mixing
> with
> > other softwares. GPL is fine with end user software built on top of LGPL
> libs.
> > That said, it would require to relicence all qgis source code as LGPL
> with all
> > contributors agreeing to the change.
> 
> I don't think this will happen soon both for logistical reasons and
> philosophical - many of us who have contributed code to the project
> would object to the license switch.

Since QGIS includes a server application now, perhaps you should consider 
relicensing under the *more* restrictive AGPL ;)

Does anyone know about distributing *only source code* as *public domain* for a 
plugin which links with proprietary software?
I think it would not be allowed, but I'm not sure.

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

RE: [Qgis-developer] Directions needed for GSOC Proposal

[Alister Hood]

> Date: Sat, 24 Mar 2012 23:20:34 +0530
> From: "arunthe...@gmail.com" 
> Subject: [Qgis-developer] Directions needed for GSOC Proposal
> To: qgis-developer 
> Message-ID:
>   
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hello all,
> 
> There have been prevoius discussions about this GSOC thing. Adding
> analytical power to the software can be the best thing that can be done to
> QGIS. Initially I was of the idea of porting fTools to C++, but then
> realized the processing framework to be a better option. Now that there
> are
> two frameworks on the prowl, its getting a bit difficult to draft the
> proposal.
> 
> Which one is going to be adopted? And is the one that will be adopted
> ready
> to take in a GSOC student and provide mentoring? While I have been  a
> self-learner for the most part, its still a serious thing when we talk
> about code going live into the project.
> 
> Or should I probably throw in the towel and pick up something like
> Symbology improvements?
> 
> Directions please.

What symbology improvements would you be looking at doing?  There are quite a 
few tickets for improvements to the automatic labeling ;)

Ftools seems to have taken the limelight, but what about the idea of a suite of 
topology tools, which I also mentioned at the same time as the ftools idea?  It 
really came from Alexandre 
(http://lists.osgeo.org/pipermail/qgis-user/2011-May/012060.html), but it's 
something that QGIS users often say they need to use another GIS for.
Would this also be tied up with the processing framework like the Ftools idea 
is?

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

[Qgis-developer] Re: Removing old labelling

[Alister Hood]

> > On 03/11/2012 11:55 AM, Martin Dobias wrote:
> >> Anyway it's worth noting that when rendering text there are two
> possibilities:
> >> 1. draw text (old labeling) - faster, hard to draw buffers (currently
> >> being drawn by shifting the text several times) 2. convert text to
> >> vector path + draw path (new labeling) - slower, but with nice
> >> buffers (antialiased etc). Problems: text is converted to vectors ->
> >> harder postprocessing, bigger buffers are not drawn correctly.
> >>
> >> Martin
> >
> > Ah, that explains why the text isn't exported as text in svg files.
> > Would it be possible or make sense to do both. E.g. the text stays
> > text but a copy is converted and buffers are generated on the copy
> > that is a path?
> 
> I haven't tried that but I expect that it will not look good because the
> rendering algorithms are different.
> 
> I will be probably moving new labeling to use directly text drawing in
> future since path drawing is several times slower...
> 
> Martin

For what it's worth - the PDFs I've seen produced by ArcGIS and Mapinfo do have 
the text as text and the buffer as a path, but the buffer is quite simplified, 
at least for small text (and it can look quite bad).

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

Re: [Qgis-developer] Plugin development from amateur...

[Alister Hood]

> Date: Wed, 7 Mar 2012 16:54:48 +0100
> From: Werner Macho 
> Subject: Re: [Qgis-developer] Plugin development from amateur...
> To: jr.morre...@enoreth.net
> Cc: qgis-developer@lists.osgeo.org
> Message-ID:
>   
> Content-Type: text/plain; charset=UTF-8
>
> Hi!
>
> I just want to think public about this "forking" plugins problem:
>
> IMHO if the "old" functionality is preserved and the plugin is
> extended and has the same functionality plus a little (a lot) more..
> than it would be good to contact the maintainer and collaborate with him..
>
> If the old functionality is gone and it is a pretty much new plugin
> I'd vote to create a new plugin and give credits to the "inspirator"
> of the former plugin with "based on the plugin xyz created by" ..
>
> just my 2??
>
> kind regards
> Werner

But surely if the new plugin still uses any code from the old plugin it will 
need to retain its copyright notices and license.  Credit for "inspiration" 
won't be enough.

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

Re: [Qgis-developer] GSoC ideas

[Alister Hood]

Something that has been mentioned by a few people, and would probably be very 
popular, I described like this:

"Vector editing/geoprocessing tools or whatever they are called, like the ones 
found in the Mapinfo 'Object' menu - i.e. similar to ftools, but taking sets of 
selected features as inputs, instead of whole layers."
http://woostuff.wordpress.com/2011/05/17/the-things-i-would-like-to-see-in-qgis-what-are-yours/
http://lists.osgeo.org/pipermail/qgis-user/2011-May/012041.html

Later in that second thread someone also mentioned the following; I think other 
people have also made similar requests/suggestions:

"I guess implementing topology rules and visualizing the existing errors would 
be a way to identify and correct problems like polygon overlapping.  It might 
already exist some code."

This second idea would probably require more research and thinking about 
exactly what to do.  

I think both these ideas are complementary, and could perhaps be done in a 
single project.  But I guess they are also features that might be able to 
attract other sponsors - you might think it is better to use Google money to do 
something which is unlikely to get sponsorship otherwise.

Regards,
Alister


Somebody started working on a plugin similar to this (early last year I think), 
but it didn't get very far.

> Date: Thu, 23 Feb 2012 15:31:02 +0100
> From: jr.morre...@enoreth.net
> Subject: Re: [Qgis-developer] GSoC ideas
> To: 
> Message-ID: 
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On Tue, 21 Feb 2012 17:03:15 +0200, Alexander Bruy wrote:
> > Hi all,
> >
> > Google Summer of Code 2012 is announced few weeks ago and as far as
> > I know OSGeo will participate. Hope QGIS will participate too. I 
> > started
> > wiki page for collecting ideas [0]
> >
> > Maybe we should announce also to the user list asking for ideas too
> >
> > [0] http://hub.qgis.org/wiki/quantum-gis/Google_Summer_of_Code_2012
>
> Hi,
>
> how about these projects :
>
> 1. Update and merge the multithread branch
>
> 2. QGIS, Valgrind & Co
>
> Both would get the student to put its hand in all the dark corners of 
> QGIS and both would produce a positive and visible impact.
>
> Regards,
> Jean-Roc
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] bug reporting guidelines - definition of "low" priority

[Alister Hood]

Hi everyone,
The bug reporting guidelines at http://hub.qgis.org/wiki/quantum-gis/Bugreports 
define "low" priority as "a problem which doesn't affect QGIS usefulness, and 
is presumably trivial to fix".
I think this description is a little confusing and we should delete the second 
part.
Something can be low priority but non-trivial to fix.  The definitions for the 
other levels of priority do not say anything about how easy something is to fix.
Does anyone disagree with changing this?

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

FW: [Qgis-developer] Windows Installation broken - and cannot uninstall

[Alister Hood]

My message below is waiting for moderator approval due to the attachment.
Here's a link instead:
http://dl.dropbox.com/u/24564149/ERDAS%20ECW%20JPEG2000%20SDK%20Read-Only%20License.doc

> -Original Message-
> From: Alister Hood 
> Sent: Friday, 10 February 2012 3:02 p.m.
> To: 'Tim Sutton'
> Cc: qgis-developer@lists.osgeo.org
> Subject: RE: [Qgis-developer] Windows Installation broken - and cannot 
> uninstall
>
> Hi Tim,
>
> > -Original Message-
> > From: Tim Sutton [mailto:li...@linfiniti.com]
> > Sent: Thursday, 9 February 2012 9:26 p.m.
> > To: Alister Hood
> > Cc: qgis-developer@lists.osgeo.org
> > Subject: Re: [Qgis-developer] Windows Installation broken - and cannot 
> > uninstall
> >
> > Hi
> >
> > On Wed, Feb 8, 2012 at 4:26 PM, Alister  Hood  
> > wrote:
> >
> > -8<---snip
> >
> > > - I'm not convinced the OSGeo4W installer is very risky.  Are people 
> > > having problems with it without doing an "advanced install" and 
> > > choosing weird things?  IMO the only good reason for recommending 
> > > the standalone installer is that OSGeo4W doesn't provide ECW libs 
> > > (but the standalone installer isn't actually respecting the license 
> > > on these,
> > > anyway...)
> >
> > Actually the standalone is widely used by people with low bandwidth because 
> > the typical pattern is for one person to sacrifice the time / money to 
> > download it and then share it widely saving others the expense and time of 
> > doing the same.
>
> Well, people are free to do what they want, but if I had bandwidth or speed 
> restrictions I would be even more motivated to use the OSGeo4W installer.
> I guess it is slightly more complicated to share the directory of downloaded 
> packages, but it's still easy, really.  I do it myself whenever I install on 
> a different computer, and I don't even need to worry about bandwidth or speed 
> here.
>
> > Secondly, we did have an agreement with ERMapper to redistribute the 
> > ECW libs
>
> Sorry, just to clarify - are you saying someone here contacted  ERMapper and 
> made a special agreement for distributing them with QGIS?  Is this recorded 
> somewhere?  I do know I'm not the only one who refers to the normal ECW 
> license whenever the topic comes up...
>
> (I believe the agreement should be in the installer bundle),
>
> I'm not sure if there is anything about this displayed during the install 
> process, but once installed there is a file in the install directory called 
> "ECW_EULA.txt".  This is a copy of the license for the "old" ECW version, the 
> one which is also available on Linux.
> But the actual ECW dlls included with the standalone installer are from the 
> "new" ECW version, which is normally under a much more restrictive license 
> (attached in an evil proprietary format ;) ).
> Is there an agreement that says QGIS can distribute the new dlls under the 
> old license?  Or have the dlls been updated in error?  Or has the license not 
> been updated in error?
> There is always the option of using the old ECW version, which could also be 
> distributed with OSGeo4W, and would even allow for writing ECWs...
>
> > although I am unclear as to whether the acquisition of ERMapper by Erdas 
> > has impacted on that agreement. 
>
> The ECW dlls included with the standalone installer claim to be produced by 
> Erdas.  If the agreement was made before this version of the dlls was 
> released, it seems unlikely that it would apply to them.
>
> It would be good to clarify this whole issue to make sure we're getting it 
> right, and put an explanation somewhere prominent that we can refer people to 
> instead of rehashing the discussion on a regular basis.
>
>
> Alister
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Re: Windows Installation broken - and cannot uninstall

[Alister Hood]

> Date: Wed, 8 Feb 2012 21:35:20 +0100
> From: Andrea Peri 
> Subject: [Qgis-developer] Re: Windows Installation broken - and cannot
>   uninstall
> To: qgis-developer ML 
> Message-ID:
>   
> Content-Type: text/plain; charset="iso-8859-1"
>
> >* 2. Is it really so necessary to dissuade people from using the 
> >OSGeo4W*>* "Setup"?*>* - It is much quicker and easier.  E.g. when a 
> >new version of QGIS is*>* released you only need to click through setup 
> >again to update.  You don't*>* need to go to the QGIS website, download 
> >a new installer (which will waste*>* time and bandwidth because it is 
> >bigger - especially since it includes*>* GRASS, which many people would 
> >never use), run the installer, and*>* separately run the uninstaller 
> >for the old version.*>* - The OSGeo4W setup also provides easy access 
> >to other software you might*>* want to use with QGIS (and nightlies in 
> >case you need them :) )*
>
>
> A problem with the osgeo-setup is that the newbye user could run an "install 
> all"  and so install on its machine the web softwares.
> When this was happened , the machine begin to run slow. And the remove of the 
> web software was a bit of panic, expecially from the services.

But there is no option to "install all".  Am I missing something?

Alister

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

Re: [Qgis-developer] Windows Installation broken - and cannot uninstall

[Alister Hood]

Hi guys,
Two things:


> No un-installation is required when working with OSGeo4w normally.
> However if you wish to uninstall simply delete the C:\OSGeo4w folder.
> OSGeo4w has very few registry entries (1-4 I think)

1. But if you only want to uninstall certain things, just run through the 
OSGeo4W "setup" program again, and unselect them.  "Setup" is used for 
everything, like a Linux package manager - 
adding/removing/upgrading/downgrading packages.


> Use the standalone installer, is less risky to have something get wrong.

2. Is it really so necessary to dissuade people from using the OSGeo4W "Setup"?
- It is much quicker and easier.  E.g. when a new version of QGIS is released 
you only need to click through setup again to update.  You don't need to go to 
the QGIS website, download a new installer (which will waste time and bandwidth 
because it is bigger - especially since it includes GRASS, which many people 
would never use), run the installer, and separately run the uninstaller for the 
old version.  
- The OSGeo4W setup also provides easy access to other software you might want 
to use with QGIS (and nightlies in case you need them :) )
- I'm not convinced the OSGeo4W installer is very risky.  Are people having 
problems with it without doing an "advanced install" and choosing weird things? 
 IMO the only good reason for recommending the standalone installer is that 
OSGeo4W doesn't provide ECW libs (but the standalone installer isn't actually 
respecting the license on these, anyway...)

> This is important for the QGIS project because the lack of good
> installation/uninstallation procedures fuel the perception that Open Source
> projects aren't serious contenders to the traditional commercial products.

I believe the OSGeo4W installer is a much better system than a standard Windows 
installer.  But maybe its labelling and public profile could be improved.  Some 
possibilities:
- always install "setup" - make it a dependency of every other package.
- change the label of "setup" in the start menu to something which makes it 
really obvious that this is how you add/remove/upgrade/rollback packages.  
(Note that this is explained on the first page of the setup program.  If people 
choose not to install the standalone package recommended for beginners, and 
don't bother to read the instructions in the OSGeo4w installer, well...).
- Relabel the three options in the first screen of the installer to explain 
more fully what each does.
- Rewrite the explanation above these options - try and make it more concise so 
people read it and take it in.
- Mention on the download page that you just run "setup" again to 
add/remove/upgrade/rollback something.  Maybe repeating this information here 
will help ;)
- Explain that if you want to remove _everything_ you can just delete the main 
OSGeo4W folder.

I guess it would be _possible_ to make the osgeo4w installer automatically 
install "setup", and put something in the Windows "add remove programs" to 
launch it, but it would require more work...

Does anybody think those changes would be worthwhile?


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

Re: [Qgis-developer] Criticism of lack of symbols in QGIS

[Alister Hood]

> Date: Sun, 05 Feb 2012 12:54:29 +0100
> From: Paolo Cavallini 
> Subject: Re: [Qgis-developer] Criticism of lack of symbols in QGIS
> To: qgis-developer@lists.osgeo.org
> Message-ID: <4f2e6df5.7090...@faunalia.it>
> Content-Type: text/plain; charset=UTF-8
>
> Il 05/02/2012 11:05, MORREALE Jean Roc ha scritto:
> > Hi, at the moment I don't think it woulb be wise to include that much 
> > symbols without
> > changing the way they are presented to user. They have to be sorted in 
> > categories and
> > never loaded all at once.
>
> Agreed; this has been discussed several times, I think there is a ticket 
> opened on it.

Yes, the Battle of Hastings ticket :)
http://hub.qgis.org/issues/1066
We should probably close my ticket as a duplicate: 
http://hub.qgis.org/issues/4055
I don't think there is a significant difference between the two...

> I think we should:
> - divide the symbols into categories
> - avoid re-rendering the preview (very slow for hundreds of symbols), 
> possibly caching it
> - add a plugin, similar to the plugin installer, to download (better also 
> upload)
> sets of symbols from a common repo.
> It should not be a lot of work, any taker? Any sponsor?
> All the best.

I guess there would need to be a default folder to add symbols to in the user's 
profile*, and the gui would need to merge categories that are duplicated in 
more than one of the SVG search paths.

* Wouldn't it be nice if there could be a standard location to install symbols 
that was _shared with other software_, rather than each program saving them in 
its own folders?

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

RE: [Qgis-developer] [PROPOSAL] From srs.db to file-based CRS storage

[Alister Hood]

Hi,

> -Original Message-
> From: Richard Duivenvoorde [mailto:rdmaili...@duif.net] 
> Sent: Tuesday, 31 January 2012 10:53 p.m.
> To: Alister Hood
> Cc: qgis-developer@lists.osgeo.org
> Subject: Re: [Qgis-developer] [PROPOSAL] From srs.db to file-based CRS storage
>
>
> > Yes, favourites would be particularly handy.  I think the best way of 
> > implementing them would be to have a little button next to each entry in 
> > the recent list to "pin" it to the list.
> > This would be nice and quick and simple.  Does anybody actually use enough 
> > CRSs that they really need something more complicated?
>
> Hi Alister,
>
> are you on 1.7.x or on master? Because the crs selector has had an overhaul 
> in master, eg having a filterbox which looks into all fields (names, epsg 
> codes etc).

I'm on master as always ;)
I had assumed the others who were talking about bookmarks and things are also 
familiar with the new dialog, but I could be wrong.

> And has a 'recently used' list, containing your 8 last used crs's
>
> Does that not for fill your wishes?

Not really - any time you need to work with a few unusual crses, your 
"favourite" crses will drop off the list.

Personally I don't really have a problem because I only have a couple of 
favourite crses and I can find them very quickly with the filter.  But not 
everyone is like me.

A couple of others have mentioned the idea of bookmarks - I was just suggesting 
a convenient way (pinnable recent items) to implement them without making the 
user interface more complicated than it needs to be.

Of course, for that suggestion to work well when people use a lot of crses it 
would also require either:
- the list length to be configurable (or at least more than 8 items), and/or
- the list to show 8 items (or whatever) + however many favourites they define.

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

Re: [Qgis-developer] [PROPOSAL] From srs.db to file-based CRS storage

[Alister Hood]

> Date: Mon, 30 Jan 2012 12:55:21 -0800
> From: Tyler Mitchell 
> Subject: Re: [Qgis-developer] [PROPOSAL] From srs.db to file-based CRS
>   storage
> To: Alexander Bruy 
> Cc: qgis-user ,Qgis Developer List
>   
> Message-ID: <6c5840aa-afa3-4189-b276-aa2873a21...@locatepress.com>
> Content-Type: text/plain; charset=us-ascii
>
> On 2012-01-30, at 11:58 AM, Alexander Bruy wrote:
>
> > Hi all,
> > 
> > currently QGIS used srs.db to store projection definitions. But with
> > this approach
> > users can't reorganize CRS definitions as they want (always used predefined 
> > tree
> > with predefined groups).
>
> Instead, why not extend the current CRS look up tool to allow for custom 
> folders,
> re-ordering or "favourites"?
> Ideally, create a CRS Manager app to do it. From
> what I've seen most users (ok, maybe just me) won't use more CRS 
> than in their "recently used list" --which works well for me :)
> ...

Yes, favourites would be particularly handy.  I think the best way of 
implementing them would be to have a little button next to each entry in the 
recent list to "pin" it to the list.
This would be nice and quick and simple.  Does anybody actually use enough CRSs 
that they really need something more complicated?

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

Re: [Qgis-developer] Adding expressions support for layer's actions

[Alister Hood]

> Date: Tue, 10 Jan 2012 21:22:51 +0200
> From: Tim Sutton 
> Subject: Re: [Qgis-developer] Adding expressions support for layer's
>   actions
> To: cavall...@faunalia.it
> Cc: qgis-developer@lists.osgeo.org
> Message-ID:
>pnvU4B7=egaod8_uqdjsjsosgeugstytojra...@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Hi
> 
> On Sun, Jan 8, 2012 at 9:30 AM, Paolo Cavallini

> wrote:
> > Il 08/01/2012 01:24, Giuseppe Sucameli ha scritto:
> >
> >
> >> In addition, should I drop the old behavior (I think it's better,
> but it
> >> breaks
> >> API) or support both them (i.e. adding a version property for
> actions) or
> >> keep the old behavior for compatibility only (adding an option in
> the
> >> settings
> >> dialog)?
> >
> >
> > +1 for the first solution.
> > Also, please note that the interface should be streamlined, avoiding
> the
> > need to apply & update the action, etc.
> >
> 
> Also if you are thinking about actions, it would be nice to have a new
> maptool called 'feature action' that runs an action directly when
> clicking a feature (or maybe pops up an action list when more than one
> action has been defined for a layer). The actions is such cool
> functionality but the number of mouse clicks required makes it too far
> away to be convenient to use.
> 
> Regards
> 
> Tim

That feature would close http://hub.qgis.org/issues/119

Also see http://hub.qgis.org/issues/4262 and
http://hub.qgis.org/issues/4211 if you're improving actions.


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

RE: [Qgis-developer] Benchmarking QgsExpression against V8

[Alister Hood]

Hi,

I think the language for expressions should be considered carefully.  It
can have a fairly big impact on user experience, particularly for people
who aren't programmers.

What other candidates might there be?  How do they compare in terms of
intuitiveness?  The less time people need to spend reading the help
every time they build an expression, the better.

Alister

> Date: Tue, 10 Jan 2012 01:00:11 +0100
> From: Pirmin Kalberer 
> Subject: [Qgis-developer] Benchmarking QgsExpression against V8
> To: qgis-developer@lists.osgeo.org
> Message-ID: <2052129.lmK783bSmN@polarwind2>
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi all,
> 
> Following the recent enhancements of QGsExpression, I was wondering
> whether it
> wouldn't make sense to integrate a language intepreter instead of
> creating
> another language.
> One candidate would be Google's V8 JavaScript engine
> (http://code.google.com/p/v8/). Since embedding this C++ library is
> easy, I've
> conducted a few quick benchmarks against QgsExpression. Code is
> attached.
> 
> Test 1:
> Qgs: '1' || '2' || '3' || '4' || '5' || '6' || '7' || '8' || '9' ||
'0'
> total_avg: 3.380211
> V8: '1' + '2' + '3' + '4' + '5' + '6' + '7' + '8' + '9' + '0'
> total_avg: 0.556035
> Fact: 6.0791335
> 
> Test 2:
> Qgs: 1+1=2 AND 5>1
> total_avg: 4.072254
> V8: 1+1==2 && 5>4
> total_avg: 0.864054
> Fact: 4.7129624
> 
> Test 3:
> Qgs: replace(lower( 'AAxx'), 'xx', 'BB')
> total_avg: 3.480217
> V8: 'AAxx'.toLowerCase().replace('xx', 'BB')
> total_avg: 0.856053
> Fact: 4.0654224
> 
> Test 4:
> Qgs: regexp_replace( 'AAxx', 'x+', 'b')
> total_avg: 2.952184
> V8: 'AAxx'.replace(/x+/, 'b')
> total_avg: 0.668042
> Fact: 4.4191593
> 
> Test 5:
> Qgs: CASE WHEN (15 = 11 or 15 = 13 or 15 = 15 or 15 = 21) THEN 15 END
> total_avg: 1.4664916
> V8: if ([11,13,15,21].indexOf(15)>=0) { 15 }
> total_avg: 0.2672168
> Fact: 5.4880217
> 
> This benchmarks show that QgsExpression evaluation is between 4 to 6
> times
> slower than V8. This is much better than I expected, but it's still
> factor 4
> to 6...
> So I think it's worth discussing pros and cons of using V8 as an
> expression
> engine. I see the following points:
> 
> Pros:
> -Better performance
> -Full Javascript language set included
> -Possibility for writing custum functions
> 
> Cons:
> -New language for expressions
> -More fat (3.7MB for libv8.so)
> 
> V8 would be a new runtime dependency but would replace the flex and
> yacc build
> dependencies.
> 
> Any other points?
> 
> Regards
> Pirmin
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] bug instructions: a simple proposal

[Alister Hood]

Hi everyone,
I have some suggestions for http://hub.qgis.org/wiki/quantum-gis/Bugreports

- Instruct users to use the preview button when creating or commenting on a bug 
report.  (I have used the hub a lot, but still sometimes I expect things to 
appear differently than they actually do).

- Instruct users to only use the edit button on comments to make minor changes 
(e.g. correcting typos).  This is because there is no email update when a 
comment is edited.

- The definitions to be used for determining the Priority of a ticket are 
currently oriented only towards bugs.  I think there should be some additional 
guidance for determining the Priority of feature requests.
(even if the guidance is "All feature requests are to be assigned 'Normal' 
priority".  But I'm not proposing that should be the guidance - I think some 
feature requests are much more important than others.)


Regards,
Alister
<>___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

RE: [Qgis-developer] WMS Error when accessing layer properties

[Alister Hood]

Note that this particular issue has apparently been fixed in trunk.


> -Original Message-
> From: Alister Hood
> Sent: Friday, 23 December 2011 11:34 a.m.
> To: 'qgis-developer@lists.osgeo.org'
> Cc: 'james.st...@npaconsult.co.uk'
> Subject: RE: [Qgis-developer] WMS Error when accessing layer
properties
> 
> I think the best you can do on windows is to use debugview
> http://live.sysinternals.com/Dbgview.exe
> 
> Alister
> 
> > Date: Thu, 22 Dec 2011 10:56:28 -
> > From: "James Stott" 
> > Subject: RE: [Qgis-developer] WMS Error when accessing layer
> > properties
> > To: "Ivan Mincik" 
> > Cc: qgis-developer@lists.osgeo.org
> > Message-ID:
> 
> > Content-Type: text/plain;   charset=utf-8
> >
> > How would I get the debug output and gdb backtrace so I can submit
> > them?
> >
> >
> > James Stott BSc (Hons) MSc | Senior Professional
> > Nicholas Pearson Associates | 30 Brock Street | Bath | BA1 2LN
> > T: 01225 445548 | M: -
> > http://www.npaconsult.co.uk/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Symbol properties dialog from plugin

[Alister Hood]

> Date: Thu, 22 Dec 2011 07:50:11 +0100
> From: Denis Rouzaud 
> Subject: Re: [Qgis-developer] Symbol properties dialog from plugin
> To: qgis-developer@lists.osgeo.org
> Message-ID: <4ef2d323.4030...@gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
...
> 
> BTW, I just applied to this list, and I don't really know how to
answer
> emails as I checked the daily digest option. Does anyone has a tip?

Yes, it is quite painful.  This is what I do:
- Make sure my mail client is set up to put this in front of each line
of the email I'm replying to: "> "
- Click reply.
- Delete all the messages I'm not replying to.
- Particularly if I'm replying to a long thread, trim some of it away if
it seems like a good idea.
- Replace the Subject line with the one from the message I am replying
to.
- Add the person I am replying to as a Cc (and maybe other people in the
thread).

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

RE: [Qgis-developer] WMS Error when accessing layer properties

[Alister Hood]

I think the best you can do on windows is to use debugview
http://live.sysinternals.com/Dbgview.exe

Alister

> Date: Thu, 22 Dec 2011 10:56:28 -
> From: "James Stott" 
> Subject: RE: [Qgis-developer] WMS Error when accessing layer
>   properties
> To: "Ivan Mincik" 
> Cc: qgis-developer@lists.osgeo.org
> Message-ID: 
> Content-Type: text/plain; charset=utf-8
> 
> How would I get the debug output and gdb backtrace so I can submit
> them?
> 
> 
> James Stott BSc (Hons) MSc | Senior Professional
> Nicholas Pearson Associates | 30 Brock Street | Bath | BA1 2LN
> T: 01225 445548 | M: -
> http://www.npaconsult.co.uk/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] RE: "Known Issues" list

[Alister Hood]

Hi guys,

> Date: Sat, 17 Dec 2011 21:07:01 +0100
> From: Agustin Lobo 
> Subject: [Qgis-user] Re: [Qgis-developer] Georeferencer produces wrong
>   (shifted) result
> To: Manuel Massing 
> Cc: qgis-user ,
>   qgis-developer@lists.osgeo.org
> Message-ID:
>
 m>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Many thanks Manuel.
> No hurry for including the patch, once the problem is identified and
> you even provide a simple way to circumvent it.
> What is needed is to have users know of these potential problems, ie.
> through
> a note of "Known Problems" included in the release mentioning that
> "the Georeferencer plugin requires users to check that their files do
> not include
> an implicit geotransform and use e.g.
> "gdal_translate -co "PROFILE=BASELINE" -of GTiff Ilerfly125v2.tif
> Ilerfly125v2-nogeotrans.tif"
> to remove it in case this is actually needed".
> In other words, once the problem is identified and warned, users can
> rely on using the software for the rest of cases.
> The question is thus that, in addition of the excellent developers
> already involved,
> we need a team of users and a battery of tests to be regularly
> performed.
> Agus
> 
> ...
> 
> Date: Sat, 17 Dec 2011 21:12:23 +0100
> From: Werner Macho 
> Subject: [Qgis-user] Re: [Qgis-developer] Georeferencer produces wrong
>   (shifted) result
> To: agustin.l...@ija.csic.es
> Cc: Manuel Massing ,
>   qgis-developer@lists.osgeo.org, qgis-user  u...@lists.osgeo.org>
> Message-ID:
>vmqmej6gewuwordnm4bcffqao...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Very good idea..
> Implementing a known problems per release seems possible to me. But it
> can
> only be a webpage cause at the time of release you mostly are not
aware
> of
> the problems..
> Regards
> Werner

Do you think a _wiki_ page would be a good idea, so that more people can
add things to it?

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

Re: [Qgis-developer] Plugin reorganization (again)

[Alister Hood]

> Date: Thu, 15 Dec 2011 08:31:56 +0100
> From: Paolo Cavallini 
> Subject: Re: [Qgis-developer] Plugin reorganization (again)
> To: qgis-developer@lists.osgeo.org
> Message-ID: <4ee9a26c.4090...@faunalia.it>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Il 15/12/2011 06:38, Alister Hood ha scritto:
> > Even with all the plugins in one menu they can be hard to find -
> there
> > are tickets about this:
> > http://hub.qgis.org/issues/4069
> > http://hub.qgis.org/issues/1734
> >
> > Do you think my latest suggestion at #4069 would work?:
> Hi all.
> Why not adding a compulsory tag "section": raster, vector, database,
> web, miscellaneous?
> All the best.

Will that really be enough to solve the problem of finding how to run a
plugin?

Some plugins are accessed from a category in the plugins menu, but
others create their own menu, or just install toolbar buttons, either in
the plugins toolbar or in a standard toolbar.  Maybe some are accessed
from a standard menu other than the plugins menu.
The tags you propose and the names of the standard menus and the names
of the standard toolbars don't match up.
The tooltip on each toolbar button would describe what it does, but
might not mention the name of the plugin...
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Plugin reorganization (again)

[Alister Hood]

Hi guys,
It's good to see some work in this area.

> Date: Wed, 14 Dec 2011 11:15:46 -0900
> From: Gary Sherman 
> Subject: Re: [Qgis-developer] Plugin reorganization (again)
> To: Alexander Bruy 
> Cc: Qgis Developer List 
> Message-ID: 
> Content-Type: text/plain; charset=us-ascii
> 
> On Dec 14, 2011, at 9:39 AM, Alexander Bruy wrote:
> 
> > Hi all,
> >
> > there are lot of core plugins and much more contributed. Keep all
> them in
> > single toolbar/menu decrease usability. I remember we have several
> > discussions about that, and one of the results - Raster and Database
> menus.
> >
> > But most plugins don't used appropriate menus, see [0]. So after
some
> offlist
> > discussion with Paolo I start to work on moving plugins to correct
> menus. As
> > a part of this work I also implement some new functionality:
> > - new methods to place plugin buttons to the Raster toolbar;
> > - new Vector menu (hidden by default, appears after loading first
> plugin. Same
> >   as we have with Database menu) and Vector toolbar. Methods to add
> plugins
> >   to this menu/toolbar;
> > - Database toolbar with appropriate methods.
> >
> > Also I move most of core plugins to different menus, depending on
> > their functions.
> 
> The only pitfall I see with this is if a plugin isn't loaded and the
> user loads it they may not know where to find the menu. I don't know
if
> this is the case, but when plugins used the Plugins menu, the user had
> a clue where to look.

Even with all the plugins in one menu they can be hard to find - there
are tickets about this:
http://hub.qgis.org/issues/4069
http://hub.qgis.org/issues/1734

Do you think my latest suggestion at #4069 would work?:

- A lot of plugins have an "about" page. The plugin system could be
changed so that instead of plugin authors implementing their own "about"
pages (as many do currently), there is a standard "about" page, build
from the plugin metadata, and accessible from the plugin
installer/manager.

- There could be a policy that plugin authors should explain on the
"about" page where to find the plugin in the QGIS gui.
e.g. "XYZplugin provides the ability to do xyz in QGIS, and can be
accessed from the Vector menu".
Or "WXYplugin adds a WXY tool to the standard digitizing toolbar".

- This would mean the search capability in the plugin manager/installer
would be sufficient for people to find where a plugin is. It would also
reduce gui clutter caused by plugins being put in submenus just so that
they can also provide an "about" page in the submenu.
The "about" page should also provide any needed links to a plugin's
website, tracker etc.


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

Re: [Qgis-developer] killing qgis deletes prefs?

[Alister Hood]

> Date: Thu, 08 Dec 2011 09:26:07 +0100
> From: Paolo Cavallini 
> Subject: Re: [Qgis-developer] killing qgis deletes prefs?
> To: Alexander Bruy 
> Cc: qgis-developer 
> Message-ID: <4ee0749f.9000...@faunalia.it>
> Content-Type: text/plain; charset=UTF-8
> 
> Il 07/12/2011 11:35, Alexander Bruy ha scritto:
> > I think this is known issue. At least this was discussed in mailing
> list
> > several times and if I remember correctly there is a ticket in
> redmine
> 
> I could not find it, so I opened a new one:
> http://hub.qgis.org/issues/4620
> BTW, it is not easy to me finding specific tickets (e.g. filtering
only
> open ones,
> those for a specific category, etc.): am I missing something?

I don't think you're missing something - this seems to be a major
limitation of Redmine.  See
http://www.redmine.org/issues/992

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

Re: [Qgis-developer] Re: Excel Export from QGIS

[Alister Hood]

Yes, I didn't mean that the report should _be_ data in a table.  Just that it 
should be put in the "Layers" list, and it should be possible to add it to a 
composer layout.

But I now realise if a report only applies to one layer it doesn't make sense 
to put it in the Layers list.  The report would be another way of displaying 
information about the layer (just like you can display the layer features on 
the map, or view the attribute table).  It should therefore be accessible in a 
similar way to the attribute table.  And it should be possible to add it to a 
composer layout.

N.B. JasperReports is Java based.  QGIS is very unlikely to add Java as a 
dependency (at least I hope so ;))
If I remember correctly, people were having difficulty finding a report 
generator suitable to use in QGIS.  I wonder if there are any that are 
javascript based.  Perhaps that might be an option - Tim is doing some work 
with Javascript in QGIS.

> Date: Fri, 02 Dec 2011 10:19:27 +0100
> From: Bernhard Str?bl 
> Subject: Re: [Qgis-developer] Re: Excel Export from QGIS
> To: qgis-developer@lists.osgeo.org
> Message-ID: <4ed8981f.4050...@jena.de>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> IMHO a report should be more than presenting data in a table. A report 
> presents features' data in a readable way e.g. in a table but also in 
> some kind of text and could include a map or an image of the feature.
> 
> A free report generator is JasperReports http://jasperforge.org/
> 
> Bernhard
> 
> Am 02.12.2011 09:52, schrieb Alister Hood:
> > I seem to remember some previous discussions about a report generator.
> >
> > I don't think it would replace the improvements I mentioned, if that's what 
> > you mean.
> > Also, note that the need to print attribute tables across multiple pages is 
> > very similar to the need to produce maps spread across multiple pages, so 
> > it might be good to implement it along with the long-desired mapbook 
> > generator.
> >
> > Alister
> >
> >> -Original Message-
> >> From: Alexander Bruy [mailto:alexander.b...@gmail.com]
> >> Sent: Friday, 2 December 2011 9:27 p.m.
> >> To: Alister Hood
> >> Cc: Bob and Deb; qgis-developer@lists.osgeo.org
> >> Subject: Re: [Qgis-developer] Re: Excel Export from QGIS
> >>
> >> Hi all,
> >>
> >> maybe it's better to integrate into QGIS report generator? Composer
> >> is a nice feature but it don't allow to create advanced reports.
> >> Something like FastReports [0], NCReport [1] or CrystalReports
> >> will be great adition (I know, this solutions are commercial but this
> >> is just example).
> >>
> >> [0] http://www.fast-report.com
> >> [1] http://www.nocisoft.com/
> >>
> >> --
> >> Alexander Bruy
<>___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] RE: Qgis-developer Digest, Vol 74, Issue 8

[Alister Hood]

> Date: Fri, 2 Dec 2011 22:42:22 +1000
> From: Nathan Woodrow 
> Subject: [Qgis-developer] Re: [Qgis-user] Re: ecw problems
> To: giovanni.man...@gmail.com
> Cc: qgis-u...@lists.osgeo.org, qgis-developer@lists.osgeo.org
> Message-ID:
>   
> Content-Type: text/plain; charset="windows-1252"
> 
> It seems we are allowed to ship the ecw read-only SDK on windows:
> 
> "For avoidance of doubt, this Agreement does not permit You to (a) use the
> ERDAS ECW/JP2 SDK
> Desktop Read-Only to create or distribute Server Applications or SDKs; (b)
> use the ERDAS ECW/JP2
> SDK Desktop Read-Only to create Libraries; or (c) distribute header files
> or .lib Library files included in
> the ERDAS ECW/JP2 SDK Desktop Read-Only. You _may_ distribute with your End
> Application any
> dynamically loadable object Libraries (.dll files) that are included in the
> "redistributables" directory of
> the ERDAS ECW/JP2 SDK Desktop Read-Only, and are used by your End
> Application.
> "
> I suggest that we do this. ecw is a pretty popular format and it doesn't
> look good on us to tell people to go to the ERDAS site to download
> something that may or may not work if ERDAS change the version under us.
> 
> - Nathan

Yes, I don't understand why people keep saying they can't be redistributed.

But look at that license more closely:

- you can distribute the libs with a "desktop" application, not a "server" 
application or a "library".  The way I understood this was that you generally 
couldn't distribute them with GDAL, but you might be able to argue that it 
is within the "spirit" of the license to distribute them with QGIS binary 
packages, because in that case you are providing gdal as part of  QGIS, a 
"desktop" program, rather than as a library for a developer.  (Maybe some 
people would even take the view that the GDAL utilities in a binary GDAL 
package 
are also "desktop" programs.)

- Isn't there another clause stating that your program must display a 
particular statement about the user of their copyright software, and you need 
to make sure your users agree to a license (i.e. make them click through a 
license screen like in the installers for most Windows software, and if they 
don't agree with it then it won't be installed)?

- And isn't there a clause stating that you must register the users (collect 
information about them)?  
This is the real hassle, and I think most of the other people bundling ecw 
support with free GIS packages are violating it.  I was wanting to provide a 
package of one of the ECW example programs (for editing ECW headers), but 
I really don't have the energy to organise this nonsense.

It might be easier to distribute with QGIS the old version that is used on 
Linux.


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

RE: [Qgis-developer] Re: Excel Export from QGIS

[Alister Hood]

By the way,
If/when a report generator is implemented, it might be nice if the report was 
put in the "Layers" list (just like a non-spatial table is).  And just like an 
attribute table, you could potentially add a report to a composer layout 
alongside a map.


> -Original Message-
> From: Alister Hood
> Sent: Friday, 2 December 2011 9:53 p.m.
> To: 'Alexander Bruy'
> Cc: Bob and Deb; qgis-developer@lists.osgeo.org
> Subject: RE: [Qgis-developer] Re: Excel Export from QGIS
> 
> I seem to remember some previous discussions about a report generator.
> 
> I don't think it would replace the improvements I mentioned, if that's
> what you mean.
> Also, note that the need to print attribute tables across multiple
> pages is very similar to the need to produce maps spread across
> multiple pages, so it might be good to implement it along with the
> long-desired mapbook generator.
> 
> Alister
> 
> > -Original Message-
> > From: Alexander Bruy [mailto:alexander.b...@gmail.com]
> > Sent: Friday, 2 December 2011 9:27 p.m.
> > To: Alister Hood
> > Cc: Bob and Deb; qgis-developer@lists.osgeo.org
> > Subject: Re: [Qgis-developer] Re: Excel Export from QGIS
> >
> > Hi all,
> >
> > maybe it's better to integrate into QGIS report generator? Composer
> > is a nice feature but it don't allow to create advanced reports.
> > Something like FastReports [0], NCReport [1] or CrystalReports
> > will be great adition (I know, this solutions are commercial but this
> > is just example).
> >
> > [0] http://www.fast-report.com
> > [1] http://www.nocisoft.com/
> >
> > --
> > Alexander Bruy
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

RE: [Qgis-developer] Re: Excel Export from QGIS

[Alister Hood]

I seem to remember some previous discussions about a report generator.

I don't think it would replace the improvements I mentioned, if that's what you 
mean.
Also, note that the need to print attribute tables across multiple pages is 
very similar to the need to produce maps spread across multiple pages, so it 
might be good to implement it along with the long-desired mapbook generator.

Alister

> -Original Message-
> From: Alexander Bruy [mailto:alexander.b...@gmail.com]
> Sent: Friday, 2 December 2011 9:27 p.m.
> To: Alister Hood
> Cc: Bob and Deb; qgis-developer@lists.osgeo.org
> Subject: Re: [Qgis-developer] Re: Excel Export from QGIS
> 
> Hi all,
> 
> maybe it's better to integrate into QGIS report generator? Composer
> is a nice feature but it don't allow to create advanced reports.
> Something like FastReports [0], NCReport [1] or CrystalReports
> will be great adition (I know, this solutions are commercial but this
> is just example).
> 
> [0] http://www.fast-report.com
> [1] http://www.nocisoft.com/
> 
> --
> Alexander Bruy
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Re: Excel Export from QGIS

[Alister Hood]

> As others have mentioned, many people want to export to Excel mainly
for
> formatting and printing, perhaps with some added calculations.  The
> ideal would be to improve formatting and printing in QGIS so that this
> isn't necessary.
> Spreadsheets aren't particularly great for it anyway, and doing it in
> QGIS would mean that you wouldn't need to export and format again if
the
> data is updated.
> I imagine this could eventually be quite a lot of work - perhaps it
> would be a good idea for a Summer of Code project.  I guess it would
> include work on:
> - table formatting
> - number formatting (also see #4426, although that is not about
> specifying how data in an existing column is displayed).

Actually, if virtual columns and #4426 were implemented, changing the
number format displayed in existing columns isn't completely necessary -
you could just put an expression using the proposed number format
function in a virtual column, and hide the original column.

> - virtual columns (similar to the new expression based labelling).
> - easy breaking of tables across multiple pages, page numbering etc.
>
> Some people also like to export data to Excel, modify it, and bring it
> back into GIS.  Like someone said, this is a recipe for headaches, if
> not disaster.  I think it would be great if we could identify any
> further enhancements to the attribute table and the field calculator
> which would help people not to do this.
>
> Alister
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

RE: [Qgis-developer] Re: Excel Export from QGIS

[Alister Hood]

Also see
http://fosslc.org/drupal/content/earth-observation-scientific-workflows-
distributed-computing-environment

 

From: Alister Hood 
Sent: Friday, 2 December 2011 9:01 p.m.
To: 'Bob and Deb'
Cc: Tim Sutton; qgis-developer@lists.osgeo.org
Subject: RE: [Qgis-developer] Re: Excel Export from QGIS

 

That link should be http://code.google.com/p/eo4vistrails/
<http://code.google.com/p/eo4vistrails/>  J

 

From: Bob and Deb [mailto:bobd...@gmail.com] 
Sent: Friday, 2 December 2011 8:47 p.m.
To: Alister Hood
Cc: Tim Sutton; qgis-developer@lists.osgeo.org
Subject: RE: [Qgis-developer] Re: Excel Export from QGIS

 

This discussion reminds me of the reasons why I'm excited about the
Vistrails plugin for QGIS (see
http://code.googlegroups.com/p/eo4vistrails/).  Has anyone given it a
try yet?

On Dec 1, 2011 11:34 PM, "Alister Hood" 
wrote:

Hi Tim,

> -Original Message-
> From: Tim Sutton [mailto:li...@linfiniti.com]
> Sent: Friday, 2 December 2011 7:16 p.m.
> To: Alister Hood
> Cc: qgis-developer@lists.osgeo.org
> Subject: Re: [Qgis-developer] Re: Excel Export from QGIS
>
> Hi Alister
>
> On Fri, Dec 2, 2011 at 12:55 AM, Alister Hood
>  wrote:
> > Hi everybody,
> > Just a couple of thoughts:
> >
> > As others have mentioned, many people want to export to Excel mainly
> for
> > formatting and printing, perhaps with some added calculations.  The
> > ideal would be to improve formatting and printing in QGIS so that
> this
> > isn't necessary.
> > Spreadsheets aren't particularly great for it anyway, and doing it
in
> > QGIS would mean that you wouldn't need to export and format again if
> the
> > data is updated.
> > I imagine this could eventually be quite a lot of work - perhaps it
> > would be a good idea for a Summer of Code project.  I guess it would
> > include work on:
> > - table formatting
> > - number formatting (also see #4426, although that is not about
> > specifying how data in an existing column is displayed).
> > - virtual columns (similar to the new expression based labelling).
> > - easy breaking of tables across multiple pages, page numbering etc.
> >
> > Some people also like to export data to Excel, modify it, and bring
> it
> > back into GIS.  Like someone said, this is a recipe for headaches,
if
> > not disaster.  I think it would be great if we could identify any
> > further enhancements to the attribute table and the field calculator
> > which would help people not to do this.
> >
>
> I recently used a python library called xlwt for a web project to
> generate spreadsheets. I think it should be fairly straightforward to
> create a python plugin that would allow you to do it. I'm not familiar
> with a C++ library for writing excel spreadsheets, but I guess there
> is one out there somewhere.

Sure, import/export of spreadsheet formats would definitely be nice.  It
would be great if someone implemented it.
And I'm not saying it would be a technical disaster; more of an
organisational disaster.  After a user exports to excel and formats it
all nicely for printing, they would need to export and format again
every time they want to print, if the original data changes.  Hopefully
they won't be doing much in Excel other than formatting to get the data
ready for printing, or it could get quite painful.
If they're exporting to Excel to process the data and then import it
back into QGIS, there will be all sorts of added complications e.g.
because of separating the attribute data from the features, and because
Excel won't respect and preserve the data type of each field.

I'm an engineer - I work with Word and Excel all day every day.  But
often (or perhaps mostly) they are not really the right tools for the
job, and we need to do all sorts of nasty hackery to get the job done.
Basically I'm just saying that in most of the cases where someone would
go from QGIS to Excel, Excel is not the ideal tool for the job, and with
some improvements QGIS definitely would be.

Alister
___
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] Re: Excel Export from QGIS

[Alister Hood]

That link should be http://code.google.com/p/eo4vistrails/
<http://code.google.com/p/eo4vistrails/>  J

 

From: Bob and Deb [mailto:bobd...@gmail.com] 
Sent: Friday, 2 December 2011 8:47 p.m.
To: Alister Hood
Cc: Tim Sutton; qgis-developer@lists.osgeo.org
Subject: RE: [Qgis-developer] Re: Excel Export from QGIS

 

This discussion reminds me of the reasons why I'm excited about the
Vistrails plugin for QGIS (see
http://code.googlegroups.com/p/eo4vistrails/).  Has anyone given it a
try yet?

On Dec 1, 2011 11:34 PM, "Alister Hood" 
wrote:

Hi Tim,

> -Original Message-
> From: Tim Sutton [mailto:li...@linfiniti.com]
> Sent: Friday, 2 December 2011 7:16 p.m.
> To: Alister Hood
> Cc: qgis-developer@lists.osgeo.org
> Subject: Re: [Qgis-developer] Re: Excel Export from QGIS
>
> Hi Alister
>
> On Fri, Dec 2, 2011 at 12:55 AM, Alister Hood
>  wrote:
> > Hi everybody,
> > Just a couple of thoughts:
> >
> > As others have mentioned, many people want to export to Excel mainly
> for
> > formatting and printing, perhaps with some added calculations.  The
> > ideal would be to improve formatting and printing in QGIS so that
> this
> > isn't necessary.
> > Spreadsheets aren't particularly great for it anyway, and doing it
in
> > QGIS would mean that you wouldn't need to export and format again if
> the
> > data is updated.
> > I imagine this could eventually be quite a lot of work - perhaps it
> > would be a good idea for a Summer of Code project.  I guess it would
> > include work on:
> > - table formatting
> > - number formatting (also see #4426, although that is not about
> > specifying how data in an existing column is displayed).
> > - virtual columns (similar to the new expression based labelling).
> > - easy breaking of tables across multiple pages, page numbering etc.
> >
> > Some people also like to export data to Excel, modify it, and bring
> it
> > back into GIS.  Like someone said, this is a recipe for headaches,
if
> > not disaster.  I think it would be great if we could identify any
> > further enhancements to the attribute table and the field calculator
> > which would help people not to do this.
> >
>
> I recently used a python library called xlwt for a web project to
> generate spreadsheets. I think it should be fairly straightforward to
> create a python plugin that would allow you to do it. I'm not familiar
> with a C++ library for writing excel spreadsheets, but I guess there
> is one out there somewhere.

Sure, import/export of spreadsheet formats would definitely be nice.  It
would be great if someone implemented it.
And I'm not saying it would be a technical disaster; more of an
organisational disaster.  After a user exports to excel and formats it
all nicely for printing, they would need to export and format again
every time they want to print, if the original data changes.  Hopefully
they won't be doing much in Excel other than formatting to get the data
ready for printing, or it could get quite painful.
If they're exporting to Excel to process the data and then import it
back into QGIS, there will be all sorts of added complications e.g.
because of separating the attribute data from the features, and because
Excel won't respect and preserve the data type of each field.

I'm an engineer - I work with Word and Excel all day every day.  But
often (or perhaps mostly) they are not really the right tools for the
job, and we need to do all sorts of nasty hackery to get the job done.
Basically I'm just saying that in most of the cases where someone would
go from QGIS to Excel, Excel is not the ideal tool for the job, and with
some improvements QGIS definitely would be.

Alister
___
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] Re: Excel Export from QGIS

[Alister Hood]

Hi Tim,

> -Original Message-
> From: Tim Sutton [mailto:li...@linfiniti.com]
> Sent: Friday, 2 December 2011 7:16 p.m.
> To: Alister Hood
> Cc: qgis-developer@lists.osgeo.org
> Subject: Re: [Qgis-developer] Re: Excel Export from QGIS
> 
> Hi Alister
> 
> On Fri, Dec 2, 2011 at 12:55 AM, Alister Hood
>  wrote:
> > Hi everybody,
> > Just a couple of thoughts:
> >
> > As others have mentioned, many people want to export to Excel mainly
> for
> > formatting and printing, perhaps with some added calculations.  The
> > ideal would be to improve formatting and printing in QGIS so that
> this
> > isn't necessary.
> > Spreadsheets aren't particularly great for it anyway, and doing it in
> > QGIS would mean that you wouldn't need to export and format again if
> the
> > data is updated.
> > I imagine this could eventually be quite a lot of work - perhaps it
> > would be a good idea for a Summer of Code project.  I guess it would
> > include work on:
> > - table formatting
> > - number formatting (also see #4426, although that is not about
> > specifying how data in an existing column is displayed).
> > - virtual columns (similar to the new expression based labelling).
> > - easy breaking of tables across multiple pages, page numbering etc.
> >
> > Some people also like to export data to Excel, modify it, and bring
> it
> > back into GIS.  Like someone said, this is a recipe for headaches, if
> > not disaster.  I think it would be great if we could identify any
> > further enhancements to the attribute table and the field calculator
> > which would help people not to do this.
> >
> 
> I recently used a python library called xlwt for a web project to
> generate spreadsheets. I think it should be fairly straightforward to
> create a python plugin that would allow you to do it. I'm not familiar
> with a C++ library for writing excel spreadsheets, but I guess there
> is one out there somewhere.

Sure, import/export of spreadsheet formats would definitely be nice.  It would 
be great if someone implemented it.  
And I'm not saying it would be a technical disaster; more of an organisational 
disaster.  After a user exports to excel and formats it all nicely for 
printing, they would need to export and format again every time they want to 
print, if the original data changes.  Hopefully they won't be doing much in 
Excel other than formatting to get the data ready for printing, or it could get 
quite painful.
If they're exporting to Excel to process the data and then import it back into 
QGIS, there will be all sorts of added complications e.g. because of separating 
the attribute data from the features, and because Excel won't respect and 
preserve the data type of each field.

I'm an engineer - I work with Word and Excel all day every day.  But often (or 
perhaps mostly) they are not really the right tools for the job, and we need to 
do all sorts of nasty hackery to get the job done.
Basically I'm just saying that in most of the cases where someone would go from 
QGIS to Excel, Excel is not the ideal tool for the job, and with some 
improvements QGIS definitely would be.

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

[Qgis-developer] Re: Excel Export from QGIS

[Alister Hood]

Hi everybody,
Just a couple of thoughts:

As others have mentioned, many people want to export to Excel mainly for
formatting and printing, perhaps with some added calculations.  The
ideal would be to improve formatting and printing in QGIS so that this
isn't necessary.
Spreadsheets aren't particularly great for it anyway, and doing it in
QGIS would mean that you wouldn't need to export and format again if the
data is updated.
I imagine this could eventually be quite a lot of work - perhaps it
would be a good idea for a Summer of Code project.  I guess it would
include work on:
- table formatting
- number formatting (also see #4426, although that is not about
specifying how data in an existing column is displayed).
- virtual columns (similar to the new expression based labelling).
- easy breaking of tables across multiple pages, page numbering etc.

Some people also like to export data to Excel, modify it, and bring it
back into GIS.  Like someone said, this is a recipe for headaches, if
not disaster.  I think it would be great if we could identify any
further enhancements to the attribute table and the field calculator
which would help people not to do this.

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

Re: [Qgis-developer] Unique value renderer in New Symbology?

[Alister Hood]

> Date: Wed, 30 Nov 2011 02:41:51 +
> From: Giovanni Manghi 
> Subject: Re: [Qgis-developer] Unique value renderer in New Symbology?
> To: Martin Dobias 
> Cc: qgis-developer 
> Message-ID: <1322620911.2197.128.camel@sibirica>
> Content-Type: text/plain; charset="UTF-8"
> 
...
> > >> 1. When will old symbology be removed?
> > >>
> > > I hope not before all the features that are available in the old
> one are
> > > ported in the new one. I also give many training courses and what
> people
> > > is mainly missing are:
> >
> > Some time ago we started a wiki page which was supposed to list what
> > features were present in old symbology and not present in new
> > symbology:
> >
>
http://www.qgis.org/wiki/Switching_from_Old_to_New_Symbology_and_Labeli
> ng
> 
> > Unfortunately it turned out very quickly to a wishlist. I would
> > suggest cleaning all wishes and completing missing functionality.
> 
> 
> The two missing functionalities are the ones already cited: the
overall
> transparency slider (for renderers other than the single symbol) and
> the
> chance to apply the same symbol to many different symbology classes in
> one go.

Just to clarify, as you could be interpreted as saying those are the
only two items on the "wishlist" which are missing functionalities,
available in old symbology but not new:

- Those are two more missing functionalities which could be added to the
list.

- There _are_ a number of features already on the list which are true
"missing functionalities" (not wishlist items).  And I'd say some of
them are a lot more important than those two.  For example the two under
"simple markers" are important symbology options which cannot be
controlled at all in new symbology (not just missing features which help
you control a layer's symbology more easily).

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

[Qgis-developer] RE: New QGIS logo

[Alister Hood]

I always thought it was one of the best icons and logos I'd ever seen.
Glad I'm not the only one who likes it ;)


> -Original Message-
> From: qgis-community-team-boun...@lists.osgeo.org on behalf of Mars Sjoden
> Sent: Sun 11/27/2011 9:32 AM
> To: qgis-community
> Cc: qgis-developer
> Subject: Re: [Qgis-developer] Re: [Qgis-community-team] New QGIS logo
>  
> I am just wondering what is wrong with the current QGIS icon/symbol?
> 
> Are there some complaints about it's design?
> 
> It currently seems simple, scalable, representative,
> and recognizable amongst those who currently are using QGIS.
> 
> signed,
> 
> Devil's Advocate
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] RE: Qgis-developer Digest, Vol 73, Issue 51

[Alister Hood]

> Date: Thu, 17 Nov 2011 18:32:29 +
> From: Camilo Polymeris 
> Subject: Re: [Qgis-developer] QIGS GPL -> LGPL - Tigers, Lions and
>   Bears Oh My!
> To: jr.morre...@enoreth.net
> Cc: qgis-developer@lists.osgeo.org
> Message-ID:
>

> Content-Type: text/plain; charset=ISO-8859-1
> 
> > It would be any user getting their hands on this binary. If your
client
> > gives a copy to his friend then his friend has the right to the
source (it
> > doesn't mean that YOU have to the one sending the source).
> 
> I understand it *does* mean that you have to be the one sending the
> source. If you distribute a GPL'd binary without source you have to
> include a written offer to send the source to any party that receives
> that binary, even indirectly. In general it should be easier to
> include the source in the first place

No, you need to supply the source to the client (or provide access to
it).  If the client provides a binary to a third party then it is them
who needs to provide the source, not you.
You don't have any relationship with the third party - you hold
copyright to some of the code, but you have granted the client
permission to redistribute it under the GPL.

> What I am not completely sure is if, besides the users (receivers of
> modified binaries), the original copyright holders may have a right to
> the modified sources, even if they haven't received a binary. Say,
> programmer makes modified version of QGIS for a company, and sends it
> only to them. The company has a right to the modified sources. Do the
> original QGIS devs have that right, too?

No, they don't.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

RE: [Qgis-developer] QIGS GPL -> LGPL - Tigers, Lions and Bears Oh My!

[Alister Hood]

Sorry,
Just to clarify, when I said dual licensing I obviously meant with a
commercial license, not with LGPL.

> -Original Message-
> From: Alister Hood
> Sent: Friday, 18 November 2011 11:17 a.m.
> To: 'qgis-developer@lists.osgeo.org'
> Cc: 'jr.morre...@enoreth.net'
> Subject: Re: [Qgis-developer] QIGS GPL -> LGPL - Tigers, Lions and
Bears Oh My!
> 
> > Date: Thu, 17 Nov 2011 11:09:24 +0100
> > From: jr.morre...@enoreth.net
> > Subject: Re: [Qgis-developer] QIGS GPL -> LGPL - Tigers, Lions and
> > Bears Oh My!
> > To: 
> > Message-ID: <0483f1b76ab5b27321779b86fed3b...@enoreth.net>
> > Content-Type: text/plain; charset=UTF-8; format=flowed
> >
> > While we are on this subject, I would advice the reading of the only
> > source that matters :
> >
> > http://www.gnu.org/licenses/gpl-faq.html
> >
> > About plugin's licensing :
> > http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean
> >
> > to sum it up, you release your plugin under any other license
> > recognized as compatible :
> >
> > http://www.gnu.org/licenses/license-list.html
> >
> > And now my selfish view on the subject :
> > - GPL to LGPL would need agreement of every past and present
> > contributor or the rewrite of their contributed code
> > - a dual licensing such as Qt implies that the contributor agrees to
a
> > Contribution License Agreement, honk if you like administravia
> > - giving people the possibility of releasing closed product based on
a
> > open product (even without direct modification to qgis) brings no
> > positive return to the project, allows users and clients to be tied
to
> > one company, make it easier to have segmentation of the dev effort
> >
> > Let's be honest here, if you give something to someone in the hope
that
> > someday, somehow he'll repay you then I've a good deal to offer you
:)
> 
> The idea of dual licensing is that they would pay up front to use QGIS
under a
> commercial license.  So it _would_ bring a positive return to the
project (a
> new source of revenue).  No need to hope to be repaid "someday".
> 
> This doesn't sound like a bad idea to me (if you could get the
agreement of all
> past contributors).  Better than LGPL.  But are there actually some
good dual
> licensing success stories?
> 
> Are there any commercial licenses designed to only allow licensees to
create
> specialised applications which would not compete directly with the
freely
> licensed version?  A license which did that would probably be
sufficient for a
> client like this:
>
http://osgeo-org.1803224.n2.nabble.com/Qgis-custom-buil-to-read-obfuscat
ed-
> data-td6796238.html
> 
> Personally I think dual-licensing would be worth looking into if there
was a
> real demand for it.
> 
> Alister
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QIGS GPL -> LGPL - Tigers, Lions and Bears Oh My!

[Alister Hood]

> Date: Thu, 17 Nov 2011 11:09:24 +0100
> From: jr.morre...@enoreth.net
> Subject: Re: [Qgis-developer] QIGS GPL -> LGPL - Tigers, Lions and
>   Bears Oh My!
> To: 
> Message-ID: <0483f1b76ab5b27321779b86fed3b...@enoreth.net>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> While we are on this subject, I would advice the reading of the only
> source that matters :
> 
> http://www.gnu.org/licenses/gpl-faq.html
> 
> About plugin's licensing :
> http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean
> 
> to sum it up, you release your plugin under any other license
> recognized as compatible :
> 
> http://www.gnu.org/licenses/license-list.html
> 
> And now my selfish view on the subject :
> - GPL to LGPL would need agreement of every past and present
> contributor or the rewrite of their contributed code
> - a dual licensing such as Qt implies that the contributor agrees to a
> Contribution License Agreement, honk if you like administravia
> - giving people the possibility of releasing closed product based on a
> open product (even without direct modification to qgis) brings no
> positive return to the project, allows users and clients to be tied to
> one company, make it easier to have segmentation of the dev effort
> 
> Let's be honest here, if you give something to someone in the hope
that
> someday, somehow he'll repay you then I've a good deal to offer you :)

The idea of dual licensing is that they would pay up front to use QGIS
under a commercial license.  So it _would_ bring a positive return to
the project (a new source of revenue).  No need to hope to be repaid
"someday".

This doesn't sound like a bad idea to me (if you could get the agreement
of all past contributors).  Better than LGPL.  But are there actually
some good dual licensing success stories?

Are there any commercial licenses designed to only allow licensees to
create specialised applications which would not compete directly with
the freely licensed version?  A license which did that would probably be
sufficient for a client like this:
http://osgeo-org.1803224.n2.nabble.com/Qgis-custom-buil-to-read-obfuscat
ed-data-td6796238.html

Personally I think dual-licensing would be worth looking into if there
was a real demand for it.

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

[Qgis-developer] Re: Proposed attribute table UI redesign

[Alister Hood]

> Date: Thu, 17 Nov 2011 09:18:01 +0200
> From: Tim Sutton 
> Subject: Re: [Qgis-developer] Re: [Qgis-user] Proposed attribute table
>   UI  redesign
> To: Martin Dobias 
> Cc: qgis-user ,
>   qgis-developer@lists.osgeo.org
> Message-ID:
>

> Content-Type: text/plain; charset=ISO-8859-1
> 
> Hi
> 
> On Mon, Nov 14, 2011 at 3:41 PM, Martin Dobias 
wrote:
> 
> 8<-snip---
> >
> > nice stuff. One more thing I have been thinking about is that we
could
> > do the search in a way the browsers nowadays do it: keep the widgets
> > for search hidden by default, saving further vertical space. The
> > search bar would be opened only after clicking a search button or
> > pressing the usual ctrl+F or "/" shortcut.
> >
> 
> Martin what is the possibility of making the search tool work across
> all columns efficiently? I know from training courses I give that
> selecting the appropriate column when making a search is a common
> stumbling block for many users.
> 
> Regards
> 
> Tim

Hi Tim,
Can I suggest adding an "all columns" item to the drop-down column
selector, rather than removing it?
"All columns" could be selected by default.

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

[Qgis-developer] RE: [Qgis-user] Rule based labeling ideas

[Alister Hood]

Oops, that reply didn't go to the developer list
Sorry for the double-up, user list.

> -Original Message-
> From: Alister Hood
> Sent: Friday, 4 November 2011 11:32 a.m.
> To: 'qgis-u...@lists.osgeo.org'
> Cc: 'madman...@gmail.com'
> Subject: RE: [Qgis-user] Rule based labeling ideas
> 
> Hi Nathan,
> I suggested a similar thing as part of http://hub.qgis.org/issues/4123
- have
> you seen that ticket?
> I haven't got around to splitting it up like Martin suggested :(
> I think the way I suggested dealing with labels would be simpler for
the user.
> 
> Also, at least for your second option ("ui in the labelling tab"), it
seems
> like you have only considered that users want to apply different text
to labels
> for different rules.  I think it is very common for users to want to
apply
> different formatting to the labels, e.g. larger text for highways or
large
> cities than for side streets or small towns.
> 
> Alister
> 
> 
> > Date: Thu, 3 Nov 2011 23:25:14 +1000
> > From: Nathan Woodrow 
> > Subject: [Qgis-user] Rule based labeling ideas
> > To: qgis-developer@lists.osgeo.org, qgis-user
> > 
> > Message-ID:
> >

> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > Hi all,
> >
> > I was playing around with some uDig, SLD and MapServer today and how
they
> > handle labeling features and I noticed that they do labels per class
(per
> > symbol in our case) and I remember seeing that rule based labeling
was on
> > the To-Talk-About list for the next hackfest and thought I would
throw a
> > few ideas about how I thought we could do it.
> >
> > I have written a few details about my ideas here
> > http://www.qgis.org/wiki/RuleBasedLabelingIdeas
> >
> > Would love to hear other peoples thoughts on this.
> >
> > My motivation for thinking this would be good is that it's a pretty
> > powerful feature in SLD and MapServer but all the UIs that I have
seen to
> > handle defining the labels per feature class/symbol are very below
par IMO.
> >
> > - Nathan
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] New color ramp... missing at second hit

[Alister Hood]

Yes, but if after cancelling you select an existing colour ramp before
clicking on "new color ramp" again, it works.

I think the bug is actually that when you cancel "new colour ramp" stays
selected.  
What should happen when you cancel is that the previously selected
colour ramp should be selected.

Alister

> Date: Mon, 31 Oct 2011 17:19:17 +0100
> From: Anita Graser 
> Subject: Re: [Qgis-developer] New color ramp... missing at second hit
> To: cavall...@faunalia.it
> Cc: qgis-developer 
> Message-ID:
>

> Content-Type: text/plain; charset="iso-8859-1"
> 
> I confirm this on Windows with Nightly.
> 
> Best wishes,
> 
> Anita
> 
> On Mon, Oct 31, 2011 at 3:52 PM, Paolo Cavallini
wrote:
> 
> > Hi all.
> > In Vector properties, categorized and graduated styles, if I click
on New
> > color
> > ramp..., then cancel, I cannot get the popup again (I click again on
New
> > color
> > ramp..., but nothing happens).
> > Anyone confirms?
> > All the best.
> > --
> > Paolo Cavallini - Faunalia
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

RE: [Qgis-developer] Possible GUI Enhancement for canvas Selection Editing

[Alister Hood]

Hi Mars,
Is this video intended to be public?
It says "This video is private.  If the owner of this video has granted
you access, please log in."

Alister

> Date: Sun, 30 Oct 2011 19:42:44 -0700
> From: Mars Sjoden 
> Subject: [Qgis-developer] Possible GUI Enhancement for canvas
>   Selection   Editing
> To: qgis-developer 
> Message-ID:
>

> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi,
> 
> I put together a short vid clip to try and illustrate a possible? gui
> enhancement to editing attribute values while selecting features from
the
> canvas with editing of that same feature active.
> 
> http://youtu.be/3K7s6et1a6U
> >
> > I have been editing road feature attribute values lately by visually
> > selecting roads that I know are now upgraded from Gravel to Paved
surfaces.
> > After editing a hundred of these features I started to wonder if it
would
> > be possible for the Dev's to make a feature enhancement to
streamline the
> > editing of feature attribute values via Identify Results window.
> > IF this Clip is unclear please tell me, it's the first vid clip I
have
> > done, and I have not figured out a way to visualize the direct
editing of
> > values inside the Identify Results window.
> > Thanks!
> >
> > Not sure if allowing the Identity values to be editable would
produce a
> conflict...
> 
> If it was a conflict or not possible this way, then perhaps,
> 
> double clicking a particular value could open an edit window for that
same
> specific value and active for editing, without having to scroll.
> 
> If not I'll just keep clicking away.
> 
> Thank you.
> 
> mars
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

RE: [Qgis-developer] expression builder?

[Alister Hood]

Hi Paolo,
I think "should be" means "needs to be" - not "has been".

> Date: Sun, 30 Oct 2011 16:52:33 +0100
> From: Paolo Cavallini 
> Subject: [Qgis-developer] expression builder?
> To: qgis-developer 
> Message-ID: <4ead72c1.5030...@faunalia.it>
> Content-Type: text/plain; charset=UTF-8
> 
> Hi all.
> According to http://hub.qgis.org/issues/4365 :
> 
> Nathan's new expression builder (developed for expression-based
labeling)
> should be
> integrated into field calculator dialog - that widget automatically
shows all
> existing functions.
> 
> I cannot find it - am I missing something?
> All the best.
> --
> Paolo Cavallini - Faunalia

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

[Qgis-developer] QGIS plugin for catchment analysis and modelling using PIHM

[Alister Hood]

Hi everyone,
I just want to let you know about a QGIS plugin for integrated catchment
modelling.  Some of you may have seen it already, but it seems to be
sort of languishing in obscurity.  I didn't see any mention of it in the
normal QGIS community places; only in a number of academic papers.

It originally comes from here:
http://www.pihm.psu.edu/pihmgis_home.html
Their binary and source packages are both very messy and include a very
old version of QGIS, and the source package for some reason isn't the
latest version of the plugin.
I *think* the original authors may have abandoned the QGIS plugin in
favour of a web-based system.
However, there is a public fork of the latest version here, including a
windows and a linux binary:
https://github.com/mlt/PIHM/wiki
I guess he must have contacted the authors to obtain the source.  He has
cleaned up the file tree and done some fixes, including so that it
builds with msvc, and doesn't violate the GPL.  (I wish I'd found this
earlier, because I started doing the same thing...)

The plugin provides terrain analysis features similar to the TauDEM
plugin for Mapwindow and ArcGIS (but without the fully automatic mode):
pit removal, stream network and watershed delineation, etc.  
It also runs the "Penn State Integrated Hydrologic Model", and can
produce a number of time series and spatial plots of the results.

I recommend using the tutorial (and sample data) available on the web
site:
http://www.pihm.psu.edu/pihmgis_documents.html
The built-in help documentation is the same, but is missing the
pictures!
This might also be useful:
http://www.pihm.psu.edu/Downloads/Doc/pihm_input_file_format.pdf

There are a number of interesting papers which mention it, and often
have a short description of QGIS itself, e.g.:

Community Hydrologic Model: Structure
http://cuahsi.org/chymp/thurs/RMaxwell.ppt
Multiphysics Modeling Implications for Environmental Observatories
http://cuahsi.org/chymp/wed-am/CDuffy.pdf
Model-Data Integration Framework: Watershed Reanalysis at the
Susquehanna - Shale Hills Critical Zone Observatory
http://www.cuahsi.org/chymp/20110315/Presentation_CHyMP_2011_GBhatt_mode
ldata.pdf
An Object Oriented Shared Data Model for GIS and Distributed Hydrologic
Models
http://www.personal.psu.edu/muk139/KumarEtAl_DataModel_IJGIS.pdf
The Role of Physical, Numerical and Data Coupling in a Mesoscale
Watershed Model
http://www.personal.psu.edu/muk139/Mukesh_PIHM_Dec01_2009.pdf

And this one doesn't mention it, but I know there are some people here
interested in parallelization ;) :
Domain Partitioning for Implementation of Large Scale Integrated
Hydrologic Models on Parallel Processors
http://www.personal.psu.edu/muk139/Mukesh_DP_Dec01_2009.pdf

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

RE: [Qgis-developer] Why are GML and KML not directly editable?

[Alister Hood]

Hi,

> Date: Fri, 07 Oct 2011 14:03:21 +0200
> From: Paolo Cavallini 
> Subject: [Qgis-developer] Why are GML and KML not directly editable?
> To: qgis-developer 
> Message-ID: <4e8eea89.7070...@faunalia.it>
> Content-Type: text/plain; charset=UTF-8
> 
> Hi all.
> The icon Toggle edit is deactivated in case of GML and KML, even
though the
> writing
> should be supported by OGR[0]: why is this so?
> All the best.
> --
> Paolo Cavallini - Faunalia
> www.faunalia.eu
> Full contact details at www.faunalia.eu/pc
> 
> [0]http://www.gdal.org/ogr/ogr_formats.html

You might be able to work around it by loading it via VRT.

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

[Qgis-developer] Re: tool for gui mockups (Was: Polishing QGIS)

[Alister Hood]

> On Mon, Sep 26, 2011 at 7:58 PM, Nathan Woodrow
wrote:
> FYI a good site for doing UI mockup is
> http://builds.balsamiq.com/b/mockups-web-demo/
> 
> - Nathan

Hmmm, I've never been able to find a good _free_ one before, but this
looks like it:
http://pencil.evolus.vn/en-US/Downloads/Application.aspx

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

RE: [Qgis-developer] Polishing QGIS

[Alister Hood]

Hi again,
Some more comments.  In case anyone gets bored by the first lot (further
discussion of single/multiple windows), the second lot are regarding
Nathan's tree widget suggestion.

> -Original Message-
> From: Nathan Woodrow [mailto:madman...@gmail.com]
> Sent: Monday, 26 September 2011 5:33 p.m.
> To: Alister Hood
> Cc: qgis-developer@lists.osgeo.org
> Subject: Re: [Qgis-developer] Polishing QGIS
> 
> I have to echo Alisters concerns with moving to a single window
system.
> MapInfo (and Arc as far as I know)  currently use a single window
system and
> it's a pain if you do have multiple monitors and want to use them.
> 
> In my ideal QGIS world we could have a single window system (using
tabs to
> separate the windows) but have the ability to tear each tab off into
it's own
> main window for a different monitor.  

Maybe a little off-topic, but with QT, when you tear off two things, is
it _ever_ possible to dock them to each other, like it is with .NET?  It
isn't currently possible with the dockable panes in QGIS... but it would
be very handy.

Back on topic, if you can tear off a composer layout or an attribute
table, it will really need to take any relevant part of the menu with it
(if applicable - currently there is no menu for the attribute table).
Even if it was _possible_ to control it from a menu in the main window
(which might be hidden or on a different virtual desktop), it would be
confusing.  Likewise, the main window will need to show menus relevant
to whatever is displayed in it, not the menus relevant to the torn-off
window (even if that has focus).
And the torn-off window will need its own taskbar and alt-tab entries to
be really useful.  In which case it must be a separate main window after
all, surely?  This would be similar to opening a web site in Firefox in
a new window vs a new tab.

I like to e.g. edit features in an attribute table on one screen and
switch between looking at the main QGIS window, and something else
(Excel, firefox...) on the other screen.  If the attribute table isn't a
separate top-level window, I don't think this is possible* because when
the attribute table is focused, the main QGIS window will automatically
be raised above the other program.
Perhaps someone could enlighten me: _why_ should the application have a
"single main window and set of menus".  Is it simply to conform with HIG
guidelines for something like KDE?  Are those guidelines really
appropriate for a desktop GIS?  The components of a desktop GIS (map,
print composer, attribute table editor...) perform quite distinct tasks,
and the way I personally use them it is sort of like they are separate
applications.  Like you say, Nathan, this is one of the great advantages
of QGIS.  But it is more than simply being able to use several different
components at the same time, some on different screens.  It is good to
be able to manage them along with any other window, putting some on
different virtual desktops and having them at different places in the
stacking order, etc.

* unless using a window manager's "always on top" feature.

> This model could then be adopted for 1+N
> map windows and 1+N composers.   I don't think this would be overly
hard to
> achieve but would just require some thinking with how the UI behaviors
in each
> situation.
> 
> Here is a idea using Visual Studio 2010 as an example
>
http://blogs.msdn.com/blogfiles/zainnab/windowslivewriter/thebestofvisua
lstudio
> 2010freeyourdocumen_761d/image_thumb.png
> 
> The window that is highlighted is normally docked in the main VS
window however
> you can break it out into its own window if you need in order to use
multiple
> monitors (very handy!).
> 
> This is a concept that I can up with the other day for handling the
composer
> list thing and tab interface http://imgur.com/8aA1W The idea is we
just have
> one list with the tabs (or windows) to handle the map canvas/es and
composers.
> In the case of the tree view when clicking on a item header (eg Map
Window or
> Composer 1 etc) the tab would switch focus to that window/tab and set
up the
> controls for the tab/window.  Using this model would allow you to also
drag
> layers from a map window into a composer map frame as technically the
composer
> map frame and map window are not 1:1 always with layers sets. Being
able to see
> what layers are in what frame would also be handy IMO.

That's a fantastic concept.
Here are some thoughts (I guess you are already thinking them):
- Does there really need to be any difference between a "Map Window" and
a "Map Frame"?  They could be exactly the same.  You could click on a
"Map Frame" and choose to view it (which would behave like a "Map
Window" e.g. for zooming and panning), or you could click on the
composer which contains it,

Re: [Qgis-developer] Polishing QGIS

[Alister Hood]

Hi Tim,
As a user who opens a lot of tickets which could be described as about
"polishing", this is great to hear.
I do have a comment below - I hope it isn't too long.

> Date: Sat, 24 Sep 2011 13:39:57 +0200
> From: Tim Sutton 
> Subject: Re: [Qgis-developer] Polishing QGIS
> To: Paolo Cavallini 
> Cc: qgis-developer 
> Message-ID:
>

> Content-Type: text/plain; charset=ISO-8859-1
> 
> Hi Paolo
> 
> On Sat, Sep 24, 2011 at 10:41 AM, Paolo Cavallini

> wrote:
> > Hi all.
> > Just finished (yet another) course, this time in Spain. Went well,
> > people looked very positive about it. Crashes are less and less
frequent
> > over the course of the years, even using the dev packages.
> > Now that many core issues are solved, cosmetic issues are more
apparent:
> > we suffer from duplications and inconsistencies. I have opened
several
> > tickets. I know it is a boring and unexciting job, but sooner or
later
> > we have to do it.
> > Anyone has plans to work on this?
> 
> In my mind this will be very much the mission of 2.0 - as well as
> making all the internals clutter free and consistent, we must work to
> make the ui the same. I hope to spend the upcoming hackfest working to
> build more re-usable widgets (as we have discussed and planned in
> Lisbon). Building a good widget library I believe will be a key step
> towards achieving this consistency and will have the benefit on
> centralising fixes that then propogate themselves to all parts of the
> UI that use that widget, The projection selector widget is a really
> good example of the mileage we can get from this approach - it is used
> in various parts of the ui and in many plugins.
> 
> There are some key things I think need to be done:
> 
> - adopt an activity based interface: e.g. the print composer,
> georeferencing tool and other parts of the app that also implement a
> main window ui are all kinds of wrong. There should only be one main
> window and set of menus in any application, so we need to implement
> the appropriate changes such that the menus etc update according to
> the context of the work (activity) you are doing. In the courses I
> give, people generally lose the composer window and it is not uncommon
> to see them with ten instances of composers as they lose it and create
> new ones in succession.

I'm sure you will do anyway, but I might as well say it: Please think
carefully about this sort of major change, as the current system works
very well as soon as you understand about working with multiple windows.

It can be very useful to have a number of windows open at the same time,
especially attribute tables and composer windows.
1) it is good to be able to look at several windows side by side
2) it provides a way to quickly switch between a few that you are
actually working with, so you don't need to keep searching for them in a
very large list.

What will an "activity based interface" look like, and will it provide
for these situations?  Will it work with multiple screens (and virtual
desktops), e.g. so you can have an attribute table on one screen and the
main window on another?

Will it really be better?  It seems you could end up removing powerful
functionality, essentially using a sledgehammer to break an egg, and not
really improving much.

Maybe you could achieve the same benefits by minor improvements to the
existing gui, e.g.

- add one or more widgets which allow the user to switch which layout or
attribute table is shown in the current window (Menu?  List?  Spinbox).

- change how features are accessed, to make them more (or less?) easy to
find and use.  Currently the "New print composer" menu item stands out
more than the items in the "Print composers" submenu.  It might be good
to rename the "Print composers" submenu to "Open print composer" or
"Show print composer", and give it an icon.  An alternative might be to
move "New print composer" and "Composer manager" to the top of the
"Print composers" submenu, with a separator between them and the list of
composers.  Similarly, on the toolbar there is a button for "New print
composer", but to access an existing composer from the toolbar you need
to click the "composer manager" button, select a composer, click show,
and then close the manager.  It shouldn't be this much harder to open an
existing print composer, which is a much more common task than creating
a new one.  But this could be fixed by a small change to how you open
the print composer, without redesigning the way the whole thing actually
works.
 
> - Implementing the symbology ui better. We need some kind of tree
> interface (we discussed this at the hackfest in Lisbon in some
> detail). New symbology is very confusing when you have symbols
> composed of symbols that are themselves composed of symbols. Managing
> that causes many levels of windows to be spawned and novice users
> (advanced users too I guess) can quickly lose track of where they are.
> 
> - We need to look at how simple interactions work and streamlin