change style file extension from QML to QLP #4025
Conversation
This fixes overlap with QtQuick/QtQML files and also reflects that this is more than just style, as now it contains labeling settings, widgets etc.
src/app/qgsrasterlayerproperties.cpp
Outdated
| @@ -1762,14 +1762,10 @@ void QgsRasterLayerProperties::loadStyle_clicked() | |||
| this, | |||
| tr( "Load layer properties from style file" ), | |||
| lastUsedDir, | |||
| tr( "QGIS Layer Style File" ) + " (*.qml)" ); | |||
| tr( "QGIS Layer Properties File" ) + " (*.qlp);;" + tr( "QGIS Layer Style File" ) + " (*.qml)" ); | |||
There was a problem hiding this comment.
Should we rephrase this to "QGIS Layer Style File (deprecated)" to reduce the confusion about "what's the difference between the two?"?
Is the double ;; on purpose?
There was a problem hiding this comment.
double ;; is on purpose this is the syntax for filters in Qt file dialogs.
There was a problem hiding this comment.
Or "QGIS 2 Layer Style Files"?
|
It would be nice to rename database stuff 2. I'm not involved enough to see if we can do automatic updating of this? |
|
As I can see the only thing that needs updating in the database part is the name of the field |
|
Do you think we should also ship an |
|
Hi, |
I'm not sure the contents (style XML) will be compatible in every case. |
|
@m-kuhn Adding the |
|
As QGIS 3 will introduce a lot of API breaks, I think we can also break table schema. Moreover styles definition (and other parts of the QML/QLP file) may also change during QGIS 3.0 development. |
|
I don't see breaking schema here as a good thing as QGIS 2 and 3 will share
the same DB connection. Better to extend the table or make a new one just
for 3.0
…On Mon, Feb 6, 2017 at 7:44 PM, Alexander Bruy ***@***.***> wrote:
As QGIS 3 will introduce a lot of API breaks, I think we can also break
table schema. Moreover styles definition (and other parts of the QML/QLP
file) may also change during QGIS 3.0 development.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4025 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAXS3PU5shwxHZy2cB3j5cR2d8WWvxrJks5rZuuSgaJpZM4LoJSg>
.
|
|
Well, I can add another column to the |
|
I would say cross that bridge when it comes no need to do that now. IMO
it's not a big enough deal to break the table.
If you break the table what is the solution if you want to use QGIS 2 and
QGIS 3 on the same DB?
…On Wed, Feb 8, 2017 at 7:50 PM, Alexander Bruy ***@***.***> wrote:
Well, I can add another column to the layer_styles table when creating it
from scratch and some logic to alter this table if it is already present in
a database. But at some point we anyway should drop QML column from it
otherwise we will end up with a huge table with columns for each QGIS
version, because same DB may be used by QGIS 2, QGIS 3, QGIS 4....
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#4025 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAXS3LmFgiYsnoy8Dyg6KSHTzPbV3v3sks5raY_WgaJpZM4LoJSg>
.
|
That sounds good to me. Apart from the database pollution, which only happens when migrating and not when creating from scratch, I think that sound like a sane approach? |
|
@alexbruy any news on this, it would be a nice change for 3.0? |
This fixes overlap with QtQuick/QtQML files and also reflects that this is more than just style, as now it contains labeling settings, widgets settings etc.
I only chaged corresponding strings and some variable names. Most of the variables and names of the fields in the databases left unchanged (e.g. when saving style to database). Not sure if we should change them too.