[Qgis-developer] A trip down memory lane - .avl style support in QGIS

[Tim Sutton]

Hi (apologies for brief answers I have little time left this afternoon).

2007/11/23, Martin Dobias <wonder.sk at gmail.com>:
> Hi again,
>
> I've found out that this is quite interesting topic as also for
> purposes of labeling we should be able to store labeling settings
> per-layer (and not only in project), so I have some more questions :)
>

Good - I will value your input.

> Btw. do you have already an idea how the xml file will look like?

It will be exactly the format form .qgs project files (as implemented
in readXML and writeXML function in qgsvectorlayer - qml generation &
parsing will just be calls to these methods).

> - will it have the same structure for layer properties as in .qgs project files?

Yes as above.

> - will it support multiple styles for one layer (e.g. style 1: red
> color, style 2: blue color) or for every style you would need another
> style file?

My plan was to support 1 style per file. Behaviour will be:

 - user loads file
 - vector layer ctor checks to see if qml file exists with same
basename (or using uri based check in a db for other datasource types)
 - if style exists and we are not loading from project, style is applied
 - user may open layer properties and use a 'select style file' button
to load an alternate style
 - in either case when saving as a project the style will be cloned
into the .qgs file and the qml files no longer used beyond that.


> - will it support additional data stored for layer by plugins?
>

I havent considered this.

> And how will users use it? When layer will use the default symbology
> and he will change it, will be the change be saved in project file or
> style file? Moreover will project use just link to the style file in
> case of default style or will it copy the settings always? (that could
> lead to some unpleasant behaviour like: 1. user saves project, 2. user
> changes default style for one of that layers, 3. user opens the
> project again - with old style)

Changing symbology will affect only the style persisted in the project
or inpersistently stored in the local session. To persist a style the
user will need to perform an explicit action - there will be two
additional options in vector props dialog:

 * save as default style
 * save style as...

A third button will let user backout changes

 * Revert to default style

And a fourth will let them select a style from disk:

 * load style ...

These four buttons are the only changes to the UI that I am expecting
to make that directly relate to qml support. I am at the same time
making some other ui changes to open up some space for these 4 new
buttons and to implement the fill and outline style options in combo
boxes as the current button approach uses way too much space and has
serios useability issues when the dialog gets full (e.g. using
classifiers). See attached screenie for example.

Theoretically we could add some behaviour to qgsproject to let it
choose default style over project style if found, but doing this
doesnt really make sense to me.

>
> On Nov 19, 2007 2:39 AM, Tim Sutton <tim at linfiniti.com> wrote:
> > Way 1) Add an extra bool parameter to the vector ctor with default to
> > true. When loading layers from qgsproject set this flag to false to
> > prevent having to parse the xml once during layer initialisation
> > (using qml mechanism) and once when project overrides it with its own
> > deserialised xml for the layer.
>
> I think this would be OK (other two solutions seem to be worse).
> I guess vector layer should get also functions to load and save style
> file, right?

Right - these will just be thin wrappers around readXML and writeXML
which will deserialise the qml, convert it into a dom document and
pass the top node over to read/writeXML.

>
> > As you can see my preferred way is to simply ad a flag to the ctor
> > that will determine whether we should look for the existance of a qml
> > or not. Obviously for some vector types e.g. PostGIS this flag will
> > currently be ignored though I am thinking that in these type of non
> > file based situations we could also be doing a layer URI match in the
> > users qgis.db and pull the qml out of a table there. This latter is
> > not something I will try to address in my first version yet though.
>
> For layers that are not represented as files (postgis or other
> databases) we should support styling by default too - otherwise it
> would be just a half-solution. I can imagine that every provider would
> be able to pick a .qml file for every layer it can load - for
> shapefiles provider would return the same file just with .qml
> extension instead of .shp, for database layers we could use e.g.
> ~/.qgis/qml/ directory to store styles in format e.g.:
> dbtype-hostname-port-dbname-table.
>
> What do you think of it?
>

Yes but this will require a change to every provider? And a change to
the provider API. I prefer to do this transparently to the providers
if I can - which should be simple enough since we can use the provider
key as a basis for this.

> > Assumming I go with way 1 above, how will that affect python bindings?
>
> Just a small change in .sip file for vector layers...
>
> Martin
>


Thanks for the feedback !

Regards


-- 
Tim Sutton
QGIS Project Steering Committee Member - Release  Manager
Visit http://qgis.org for a great open source GIS
openModeller Desktop Developer
Visit http://openModeller.sf.net for a great open source ecological
niche modelling tool
Home Page: http://tim.linfiniti.com
Skype: timlinux
Irc: timlinux on #qgis at freenode.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qgis_vetor_layout_issues.jpg
Type: image/jpeg
Size: 54099 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/qgis-developer/attachments/20071123/d1de1acc/qgis_vetor_layout_issues.jpg