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

Martin Dobias wonder.sk at gmail.com
Sun Nov 25 10:51:08 EST 2007


On Nov 23, 2007 6:55 PM, Tim Sutton <tim at linfiniti.com> wrote:
> 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.

I thought this could be nicely implemented in a way of "properties"
widget consisting of a table with keys in first column and with
changeable values in second column - as e.g. in qt designer.


> > 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.

Actually this could be done also without changes to providers, but
would be less roboust - e.g. we could encode URIs with some simple
generic encoding to create suitable filenames for the layers. But I
think it would be worth it to add a simple function to every provider
to determine filename for layer - I can imagine more uses for that,
e.g. plugins could use these names to store layer-specific data
there...

Martin



More information about the Qgis-developer mailing list