[QGIS-Developer] Concerns re UX of new "duplicate features" actions in 2.99

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

[QGIS-Developer] Concerns re UX of new "duplicate features" actions in 2.99

Nyall Dawson
Hi all,

Just wanted to raise discussion about a concern I have with the new
"duplicate feature" / "duplicate feature and redigitize" actions which
have been added for 3.0.

While I like the functionality, I believe we should re-think the UX of
how it is exposed in the QGIS interface.

Currently, it's implemented as a "feature action", so appears in
numerous places throughout the QGIS UI, including:
- the actions drop down submenu on the toolbar
- within the right click menu for the "identify tool"
- under the "actions" heading in the identify results dock for a feature
- in a menu bar at the top of the form shown after adding a new feature
- as an entry within the right click menu in the attribute table

So my initial concern is that exposing it in all these places is
overkill and far too prominent for this operation. But my deeper
concern is that these actions skip the edit buffer and directly alter
layers in place, even when those layers are not made editable
(https://issues.qgis.org/issues/17852). So now we've got a menu item
exposed in all these places which causes permanent changes to a layer,
including in places which are not associated with editing at all (e.g.
the identify tool right click menu).

I'm also unsure what the actions would do in some contexts - e.g. if I
create a new feature and then select "duplicate feature" in the popup
form *before* this feature has even be finalized, what does it mean?

I'd very much like to see this re-thought before our final release,
and exposed in a more standard way via the advanced digitizing
toolbar.

Thoughts?

Nyall
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Concerns re UX of new "duplicate features" actions in 2.99

Mathieu Pellerin
I share those concerns too.

The integration with parts of QGIS is sub-optimal. For e.g., the added (and always visible) menu bar in the attribute form. I'm not sure is should be there at all, and if so, certainly not when the layer's edit mode is OFF.

IMHO, I'd disable/remove less-than-optimal UI integration (such as the above mentioned example), leave the less intrusive ones in there (the action tool's actions), and revisit the UI in the 3.2 dev cycle.

Math
 

On Wed, Feb 14, 2018 at 10:34 AM, Nyall Dawson <[hidden email]> wrote:
Hi all,

Just wanted to raise discussion about a concern I have with the new
"duplicate feature" / "duplicate feature and redigitize" actions which
have been added for 3.0.

While I like the functionality, I believe we should re-think the UX of
how it is exposed in the QGIS interface.

Currently, it's implemented as a "feature action", so appears in
numerous places throughout the QGIS UI, including:
- the actions drop down submenu on the toolbar
- within the right click menu for the "identify tool"
- under the "actions" heading in the identify results dock for a feature
- in a menu bar at the top of the form shown after adding a new feature
- as an entry within the right click menu in the attribute table

So my initial concern is that exposing it in all these places is
overkill and far too prominent for this operation. But my deeper
concern is that these actions skip the edit buffer and directly alter
layers in place, even when those layers are not made editable
(https://issues.qgis.org/issues/17852). So now we've got a menu item
exposed in all these places which causes permanent changes to a layer,
including in places which are not associated with editing at all (e.g.
the identify tool right click menu).

I'm also unsure what the actions would do in some contexts - e.g. if I
create a new feature and then select "duplicate feature" in the popup
form *before* this feature has even be finalized, what does it mean?

I'd very much like to see this re-thought before our final release,
and exposed in a more standard way via the advanced digitizing
toolbar.

Thoughts?

Nyall
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Concerns re UX of new "duplicate features" actions in 2.99

pcav
Agreed, thanks Nyall for raising this point.
IMHO:
* remove duplication, leaving it only under editing
* disable it when the layer is not under editing.
All the best.

Il 14/02/2018 04:57, Mathieu Pellerin ha scritto:

> I share those concerns too.
>
> The integration with parts of QGIS is sub-optimal. For e.g., the added
> (and always visible) menu bar in the attribute form. I'm not sure is
> should be there at all, and if so, certainly not when the layer's edit
> mode is OFF.
>
> IMHO, I'd disable/remove less-than-optimal UI integration (such as the
> above mentioned example), leave the less intrusive ones in there (the
> action tool's actions), and revisit the UI in the 3.2 dev cycle.
>
> Math
>  
>
> On Wed, Feb 14, 2018 at 10:34 AM, Nyall Dawson <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi all,
>
>     Just wanted to raise discussion about a concern I have with the new
>     "duplicate feature" / "duplicate feature and redigitize" actions which
>     have been added for 3.0.
>
>     While I like the functionality, I believe we should re-think the UX of
>     how it is exposed in the QGIS interface.
>
>     Currently, it's implemented as a "feature action", so appears in
>     numerous places throughout the QGIS UI, including:
>     - the actions drop down submenu on the toolbar
>     - within the right click menu for the "identify tool"
>     - under the "actions" heading in the identify results dock for a feature
>     - in a menu bar at the top of the form shown after adding a new feature
>     - as an entry within the right click menu in the attribute table
>
>     So my initial concern is that exposing it in all these places is
>     overkill and far too prominent for this operation. But my deeper
>     concern is that these actions skip the edit buffer and directly alter
>     layers in place, even when those layers are not made editable
>     (https://issues.qgis.org/issues/17852
>     <https://issues.qgis.org/issues/17852>). So now we've got a menu item
>     exposed in all these places which causes permanent changes to a layer,
>     including in places which are not associated with editing at all (e.g.
>     the identify tool right click menu).
>
>     I'm also unsure what the actions would do in some contexts - e.g. if I
>     create a new feature and then select "duplicate feature" in the popup
>     form *before* this feature has even be finalized, what does it mean?
>
>     I'd very much like to see this re-thought before our final release,
>     and exposed in a more standard way via the advanced digitizing
>     toolbar.
>
>     Thoughts?
>
>     Nyall
>     _______________________________________________
>     QGIS-Developer mailing list
>     [hidden email] <mailto:[hidden email]>
>     List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>     <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
>     Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>     <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
>
>
>
>
> _______________________________________________
> QGIS-Developer mailing list
> [hidden email]
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>


--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Concerns re UX of new "duplicate features" actions in 2.99

Régis Haubourg
In reply to this post by Nyall Dawson
Hi, 
I totally agree. BTW, having a generic option to display some actions only in edit mode would be a nice addition for 3.2! 
Regards
Régis

Le 14 févr. 2018 04:34, "Nyall Dawson" <[hidden email]> a écrit :
Hi all,

Just wanted to raise discussion about a concern I have with the new
"duplicate feature" / "duplicate feature and redigitize" actions which
have been added for 3.0.

While I like the functionality, I believe we should re-think the UX of
how it is exposed in the QGIS interface.

Currently, it's implemented as a "feature action", so appears in
numerous places throughout the QGIS UI, including:
- the actions drop down submenu on the toolbar
- within the right click menu for the "identify tool"
- under the "actions" heading in the identify results dock for a feature
- in a menu bar at the top of the form shown after adding a new feature
- as an entry within the right click menu in the attribute table

So my initial concern is that exposing it in all these places is
overkill and far too prominent for this operation. But my deeper
concern is that these actions skip the edit buffer and directly alter
layers in place, even when those layers are not made editable
(https://issues.qgis.org/issues/17852). So now we've got a menu item
exposed in all these places which causes permanent changes to a layer,
including in places which are not associated with editing at all (e.g.
the identify tool right click menu).

I'm also unsure what the actions would do in some contexts - e.g. if I
create a new feature and then select "duplicate feature" in the popup
form *before* this feature has even be finalized, what does it mean?

I'd very much like to see this re-thought before our final release,
and exposed in a more standard way via the advanced digitizing
toolbar.

Thoughts?

Nyall
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Concerns re UX of new "duplicate features" actions in 2.99

3nids
In reply to this post by Nyall Dawson


Le mar. 13 févr. 2018 à 23:34, Nyall Dawson <[hidden email]> a écrit :
Hi all,

Just wanted to raise discussion about a concern I have with the new
"duplicate feature" / "duplicate feature and redigitize" actions which
have been added for 3.0.

While I like the functionality, I believe we should re-think the UX of
how it is exposed in the QGIS interface.

Currently, it's implemented as a "feature action", so appears in
numerous places throughout the QGIS UI, including:
- the actions drop down submenu on the toolbar
- within the right click menu for the "identify tool"
- under the "actions" heading in the identify results dock for a feature
- in a menu bar at the top of the form shown after adding a new feature
- as an entry within the right click menu in the attribute table

So my initial concern is that exposing it in all these places is
overkill and far too prominent for this operation. But my deeper
concern is that these actions skip the edit buffer and directly alter
layers in place, even when those layers are not made editable
(https://issues.qgis.org/issues/17852). So now we've got a menu item
exposed in all these places which causes permanent changes to a layer,
including in places which are not associated with editing at all (e.g.
the identify tool right click menu).

I'm also unsure what the actions would do in some contexts - e.g. if I
create a new feature and then select "duplicate feature" in the popup
form *before* this feature has even be finalized, what does it mean?

I'd very much like to see this re-thought before our final release,
and exposed in a more standard way via the advanced digitizing
toolbar.

I think it make some sense to design this as a map tool (if possible).
We don't have a simplify action, it's a map tool.

It could still be possible to add a custom action which will use the API to duplicate the feature (if one really wants this feature as an action in the form or attribute table or identify menu).

Enhancing the action API to define action on editable layers only sounds like a good addition too, but I think is not sufficient here (taking the simplify map tool as example).

My 2 cts. 

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Concerns re UX of new "duplicate features" actions in 2.99

signedav
Dear all

I agree (and I guess everyone else does), that it's not okay that this feature is enabled when the layers are not in editable mode. I already started to fix that, but because of time I had to decide to finish it next week.

Anyway, there is still the question, where it should appear. IMHO it should be everywhere, where you can add and delete features. If it's a MapTool it could be there as well, I think. I'll have to think about that.

Thanks for your inputs
Dave

14 February 2018 15:24 Denis Rouzaud <[hidden email]> wrote:


Le mar. 13 févr. 2018 à 23:34, Nyall Dawson <[hidden email]> a écrit :
Hi all,

Just wanted to raise discussion about a concern I have with the new
"duplicate feature" / "duplicate feature and redigitize" actions which
have been added for 3.0.

While I like the functionality, I believe we should re-think the UX of
how it is exposed in the QGIS interface.

Currently, it's implemented as a "feature action", so appears in
numerous places throughout the QGIS UI, including:
- the actions drop down submenu on the toolbar
- within the right click menu for the "identify tool"
- under the "actions" heading in the identify results dock for a feature
- in a menu bar at the top of the form shown after adding a new feature
- as an entry within the right click menu in the attribute table

So my initial concern is that exposing it in all these places is
overkill and far too prominent for this operation. But my deeper
concern is that these actions skip the edit buffer and directly alter
layers in place, even when those layers are not made editable
(https://issues.qgis.org/issues/17852). So now we've got a menu item
exposed in all these places which causes permanent changes to a layer,
including in places which are not associated with editing at all (e.g.
the identify tool right click menu).

I'm also unsure what the actions would do in some contexts - e.g. if I
create a new feature and then select "duplicate feature" in the popup
form *before* this feature has even be finalized, what does it mean?

I'd very much like to see this re-thought before our final release,
and exposed in a more standard way via the advanced digitizing
toolbar.

I think it make some sense to design this as a map tool (if possible).
We don't have a simplify action, it's a map tool.

It could still be possible to add a custom action which will use the API to duplicate the feature (if one really wants this feature as an action in the form or attribute table or identify menu).

Enhancing the action API to define action on editable layers only sounds like a good addition too, but I think is not sufficient here (taking the simplify map tool as example).

My 2 cts. 
<>


---------------------

David Signer

Programmer OPENGIS.CH

Wülflingerstrasse 213

CH - 8408  Winterthur

+ 41 (0) 78 766 13 03

---------------------



_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Concerns re UX of new "duplicate features" actions in 2.99

Nyall Dawson
On 15 February 2018 at 03:16, David Signer <[hidden email]> wrote:

> Dear all
>
> I agree (and I guess everyone else does), that it's not okay that this
> feature is enabled when the layers are not in editable mode. I already
> started to fix that, but because of time I had to decide to finish it next
> week.
>
> Anyway, there is still the question, where it should appear. IMHO it should
> be everywhere, where you can add and delete features. If it's a MapTool it
> could be there as well, I think. I'll have to think about that.

Thanks for your flexibility here!

What's the chance of getting this resolved before 3.0 final? If we
can't, can we please ifdef this out for 3.0 release and defer to 3.2?

Nyall


>
> Thanks for your inputs
> Dave
>
> 14 February 2018 15:24 Denis Rouzaud <[hidden email]> wrote:
>
>
>
> Le mar. 13 févr. 2018 à 23:34, Nyall Dawson <[hidden email]> a écrit
> :
>>
>> Hi all,
>>
>> Just wanted to raise discussion about a concern I have with the new
>> "duplicate feature" / "duplicate feature and redigitize" actions which
>> have been added for 3.0.
>>
>> While I like the functionality, I believe we should re-think the UX of
>> how it is exposed in the QGIS interface.
>>
>> Currently, it's implemented as a "feature action", so appears in
>> numerous places throughout the QGIS UI, including:
>> - the actions drop down submenu on the toolbar
>> - within the right click menu for the "identify tool"
>> - under the "actions" heading in the identify results dock for a feature
>> - in a menu bar at the top of the form shown after adding a new feature
>> - as an entry within the right click menu in the attribute table
>>
>> So my initial concern is that exposing it in all these places is
>> overkill and far too prominent for this operation. But my deeper
>> concern is that these actions skip the edit buffer and directly alter
>> layers in place, even when those layers are not made editable
>> (https://issues.qgis.org/issues/17852). So now we've got a menu item
>> exposed in all these places which causes permanent changes to a layer,
>> including in places which are not associated with editing at all (e.g.
>> the identify tool right click menu).
>>
>> I'm also unsure what the actions would do in some contexts - e.g. if I
>> create a new feature and then select "duplicate feature" in the popup
>> form *before* this feature has even be finalized, what does it mean?
>>
>> I'd very much like to see this re-thought before our final release,
>> and exposed in a more standard way via the advanced digitizing
>> toolbar.
>
>
> I think it make some sense to design this as a map tool (if possible).
> We don't have a simplify action, it's a map tool.
>
> It could still be possible to add a custom action which will use the API to
> duplicate the feature (if one really wants this feature as an action in the
> form or attribute table or identify menu).
>
> Enhancing the action API to define action on editable layers only sounds
> like a good addition too, but I think is not sufficient here (taking the
> simplify map tool as example).
>
> My 2 cts.
> <>
>
>
>
> ---------------------
>
> David Signer
>
> Programmer OPENGIS.CH
>
> Wülflingerstrasse 213
>
> CH - 8408  Winterthur
>
> + 41 (0) 78 766 13 03
>
> ---------------------
>
>
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Concerns re UX of new "duplicate features" actions in 2.99

Nyall Dawson
On 19 February 2018 at 16:24, Nyall Dawson <[hidden email]> wrote:

> On 15 February 2018 at 03:16, David Signer <[hidden email]> wrote:
>> Dear all
>>
>> I agree (and I guess everyone else does), that it's not okay that this
>> feature is enabled when the layers are not in editable mode. I already
>> started to fix that, but because of time I had to decide to finish it next
>> week.
>>
>> Anyway, there is still the question, where it should appear. IMHO it should
>> be everywhere, where you can add and delete features. If it's a MapTool it
>> could be there as well, I think. I'll have to think about that.
>
> Thanks for your flexibility here!
>
> What's the chance of getting this resolved before 3.0 final? If we
> can't, can we please ifdef this out for 3.0 release and defer to 3.2?
>

In https://github.com/qgis/QGIS/pull/6399 I implement a advanced
settings option, "tools\showDuplicateFeatureActions" to control
whether these actions are shown. By default it's off, but interested
organisations can set the flag in their qgis_global_settings.ini to
show these actions.

I think that's a fair approach - it means that users/organisations
which require this feature can still use it in 3.0, whilst at the same
time avoiding exposing the functionality to users by default until it
is refined.

Nyall
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Concerns re UX of new "duplicate features" actions in 2.99

signedav
In reply to this post by 3nids
Hi Nyall

I'll start with it today. So possibly it's done before the 23th.

We could keep it as an Action, only enabled when the layer is editable.
This would include an attribute of MapLayerAction, if it should be enabled only in editable mode or always (first case for the duplication-action). The user actions would need such a attribute as well. 
Probably we could integrate this attribute as another scope-value, and use the scopes as well for the MapLayerActions.
Then we need to decide on what scopes it should be displayed:
- Canvas (in the main toolbar)
- Layer (in the toolbar of attribute list)
- Feature (in the actions of attribute form, right click on a feature in the form view, right click on the feature on canvas)
- Field (right click on a field in row of attribute table, right click on field at identify result panel)

What do you think?

Thanks for the ini-configuration anyway. Probably we will need it as well. 

Regards
David

21 February 2018 05:27 Nyall Dawson <[hidden email]> wrote:
On 19 February 2018 at 16:24, Nyall Dawson wrote:
> On 15 February 2018 at 03:16, David Signer wrote:
>> Dear all
>>
>> I agree (and I guess everyone else does), that it's not okay that this
>> feature is enabled when the layers are not in editable mode. I already
>> started to fix that, but because of time I had to decide to finish it next
>> week.
>>
>> Anyway, there is still the question, where it should appear. IMHO it should
>> be everywhere, where you can add and delete features. If it's a MapTool it
>> could be there as well, I think. I'll have to think about that.
>
> Thanks for your flexibility here!
>
> What's the chance of getting this resolved before 3.0 final? If we
> can't, can we please ifdef this out for 3.0 release and defer to 3.2?
>

In https://github.com/qgis/QGIS/pull/6399 I implement a advanced
settings option, "tools\showDuplicateFeatureActions" to control
whether these actions are shown. By default it's off, but interested
organisations can set the flag in their qgis_global_settings.ini to
show these actions.

I think that's a fair approach - it means that users/organisations
which require this feature can still use it in 3.0, whilst at the same
time avoiding exposing the functionality to users by default until it
is refined.

Nyall


---------------------

David Signer

Programmer OPENGIS.CH

Wülflingerstrasse 213

CH - 8408  Winterthur

+ 41 (0) 78 766 13 03

---------------------



_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Concerns re UX of new "duplicate features" actions in 2.99

Matthias Kuhn 🌍

Hi Dave, hi Nyall,

Thanks for all your thoughts and work on this. The approach that is currently being developed sounds like a very reasonable one given the remaining time for 3.0.


Another idea I had to handle things like this was an "activate condition" for actions. The activate condition for the duplicate feature action could be a simple `@layer_editable`.

The tricky thing is, that variables (or even expression functions) used within such a construct will need to be notifiable (e.g. here upon layer edit state change, but in theory it could depend on other things like `selected_feature_count(@layer) > 2`), so the expression engine knows when an expression needs to be re-evaluated.

It will be a non-trivial thing to do and I'm not yet convinced it's worth it, but I could imagine that we find other areas in QGIS where such an interactive machinery to enable button states or change labels interactively based on expressions can come in handy.

Enjoy Madeira, I miss you all !!

Matthias


On 02/21/2018 03:55 PM, David Signer wrote:
Hi Nyall

I'll start with it today. So possibly it's done before the 23th.

We could keep it as an Action, only enabled when the layer is editable.
This would include an attribute of MapLayerAction, if it should be enabled only in editable mode or always (first case for the duplication-action). The user actions would need such a attribute as well. 
Probably we could integrate this attribute as another scope-value, and use the scopes as well for the MapLayerActions.
Then we need to decide on what scopes it should be displayed:
- Canvas (in the main toolbar)
- Layer (in the toolbar of attribute list)
- Feature (in the actions of attribute form, right click on a feature in the form view, right click on the feature on canvas)
- Field (right click on a field in row of attribute table, right click on field at identify result panel)

What do you think?

Thanks for the ini-configuration anyway. Probably we will need it as well. 

Regards
David

21 February 2018 05:27 Nyall Dawson [hidden email] wrote:
On 19 February 2018 at 16:24, Nyall Dawson wrote:
> On 15 February 2018 at 03:16, David Signer wrote:
>> Dear all
>>
>> I agree (and I guess everyone else does), that it's not okay that this
>> feature is enabled when the layers are not in editable mode. I already
>> started to fix that, but because of time I had to decide to finish it next
>> week.
>>
>> Anyway, there is still the question, where it should appear. IMHO it should
>> be everywhere, where you can add and delete features. If it's a MapTool it
>> could be there as well, I think. I'll have to think about that.
>
> Thanks for your flexibility here!
>
> What's the chance of getting this resolved before 3.0 final? If we
> can't, can we please ifdef this out for 3.0 release and defer to 3.2?
>

In https://github.com/qgis/QGIS/pull/6399 I implement a advanced
settings option, "tools\showDuplicateFeatureActions" to control
whether these actions are shown. By default it's off, but interested
organisations can set the flag in their qgis_global_settings.ini to
show these actions.

I think that's a fair approach - it means that users/organisations
which require this feature can still use it in 3.0, whilst at the same
time avoiding exposing the functionality to users by default until it
is refined.

Nyall


---------------------

David Signer

Programmer OPENGIS.CH

Wülflingerstrasse 213

CH - 8408  Winterthur

+ 41 (0) 78 766 13 03

---------------------




_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Concerns re UX of new "duplicate features" actions in 2.99

Nyall Dawson
On 22 February 2018 at 05:24, Matthias Kuhn <[hidden email]> wrote:
> Hi Dave, hi Nyall,
>
> Thanks for all your thoughts and work on this. The approach that is
> currently being developed sounds like a very reasonable one given the
> remaining time for 3.0.
>

In the meantime, I'd like to merge that PR. 3.0 is only a couple of
hours away and it makes me very nervous having this feature exposed
still. Can I merge, and then we can address whether to remove the flag
when the changes have landed?

Nyall
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Concerns re UX of new "duplicate features" actions in 2.99

Matthias Kuhn 🌍
On 02/21/2018 08:55 PM, Nyall Dawson wrote:

> On 22 February 2018 at 05:24, Matthias Kuhn <[hidden email]> wrote:
>> Hi Dave, hi Nyall,
>>
>> Thanks for all your thoughts and work on this. The approach that is
>> currently being developed sounds like a very reasonable one given the
>> remaining time for 3.0.
>>
> In the meantime, I'd like to merge that PR. 3.0 is only a couple of
> hours away and it makes me very nervous having this feature exposed
> still. Can I merge, and then we can address whether to remove the flag
> when the changes have landed?

I don't know enough about it myself, I only followed this topic marginally.

It would be good to get the green flag for it from Dave and Andreas if
somehow possible.

Regards
Matthias
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Concerns re UX of new "duplicate features" actions in 2.99

Nyall Dawson
On 22 February 2018 at 06:20, Matthias Kuhn <[hidden email]> wrote:

> On 02/21/2018 08:55 PM, Nyall Dawson wrote:
>> On 22 February 2018 at 05:24, Matthias Kuhn <[hidden email]> wrote:
>>> Hi Dave, hi Nyall,
>>>
>>> Thanks for all your thoughts and work on this. The approach that is
>>> currently being developed sounds like a very reasonable one given the
>>> remaining time for 3.0.
>>>
>> In the meantime, I'd like to merge that PR. 3.0 is only a couple of
>> hours away and it makes me very nervous having this feature exposed
>> still. Can I merge, and then we can address whether to remove the flag
>> when the changes have landed?
>
> I don't know enough about it myself, I only followed this topic marginally.
>
> It would be good to get the green flag for it from Dave and Andreas if
> somehow possible.

Yes, ideally... but also (with full respect to all involved), in its
current form this feature is just too dangerous to have in the
release. I would not feel comfortable at all in rolling out 3.0 in my
customer's organizations with the knowledge that a single accidental
slip of the mouse can permanently damage a non-editable layer.

That's why I would greatly prefer to hide it now, and then un-hide if
the issues are resolved before release.

"Better safe than sorry" and all that :)

Nyall
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Concerns re UX of new "duplicate features" actions in 2.99

Nyall Dawson
In reply to this post by signedav
On 22 February 2018 at 00:55, David Signer <[hidden email]> wrote:

> We could keep it as an Action, only enabled when the layer is editable.
> This would include an attribute of MapLayerAction, if it should be enabled
> only in editable mode or always (first case for the duplication-action). The
> user actions would need such a attribute as well.
> Probably we could integrate this attribute as another scope-value, and use
> the scopes as well for the MapLayerActions.
> Then we need to decide on what scopes it should be displayed:
> - Canvas (in the main toolbar)
> - Layer (in the toolbar of attribute list)
> - Feature (in the actions of attribute form, right click on a feature in the
> form view, right click on the feature on canvas)
> - Field (right click on a field in row of attribute table, right click on
> field at identify result panel)

Hiding the action everywhere when a layer is non-editable is a good
move. I'd also like to see it completely removed (regardless of
editable status) from:

1. The identify results right click menu and results tree view (I
think that all actions with a "only show in editable mode" flag should
be skipped from these places - the identify tool is typically a "view"
tool, not an edit tool)
2. The menu bar in the attribute form dialog (at least for newly
created features)

Thanks for your responsiveness on this!

Nyall
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Concerns re UX of new "duplicate features" actions in 2.99

signedav
In reply to this post by 3nids
Hi Nyall

It's okay for me, when you merge it to be save and we remove it, when the issue is resolved.

But I'll remove the part that the duplicate functions toggles the edit mode anyway.
So in case there will be still the action to duplicate on a not editable layer somewhere (what it shouldn't) it won't damage the layer.

Thanks and regards
Dave

21 February 2018 21:25 Nyall Dawson <[hidden email]> wrote:
On 22 February 2018 at 06:20, Matthias Kuhn wrote:
> On 02/21/2018 08:55 PM, Nyall Dawson wrote:
>> On 22 February 2018 at 05:24, Matthias Kuhn wrote:
>>> Hi Dave, hi Nyall,
>>>
>>> Thanks for all your thoughts and work on this. The approach that is
>>> currently being developed sounds like a very reasonable one given the
>>> remaining time for 3.0.
>>>
>> In the meantime, I'd like to merge that PR. 3.0 is only a couple of
>> hours away and it makes me very nervous having this feature exposed
>> still. Can I merge, and then we can address whether to remove the flag
>> when the changes have landed?
>
> I don't know enough about it myself, I only followed this topic marginally.
>
> It would be good to get the green flag for it from Dave and Andreas if
> somehow possible.

Yes, ideally... but also (with full respect to all involved), in its
current form this feature is just too dangerous to have in the
release. I would not feel comfortable at all in rolling out 3.0 in my
customer's organizations with the knowledge that a single accidental
slip of the mouse can permanently damage a non-editable layer.

That's why I would greatly prefer to hide it now, and then un-hide if
the issues are resolved before release.

"Better safe than sorry" and all that :)

Nyall
_______________________________________________
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer



---------------------

David Signer

Programmer OPENGIS.CH

Wülflingerstrasse 213

CH - 8408  Winterthur

+ 41 (0) 78 766 13 03

---------------------



_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Concerns re UX of new "duplicate features" actions in 2.99

Nyall Dawson
On 22 February 2018 at 07:15, David Signer <[hidden email]> wrote:
> Hi Nyall
>
> It's okay for me, when you merge it to be save and we remove it, when the
> issue is resolved.
>
> But I'll remove the part that the duplicate functions toggles the edit mode
> anyway.
> So in case there will be still the action to duplicate on a not editable
> layer somewhere (what it shouldn't) it won't damage the layer.

Thank you -- merged. Happy to help with the rework if you need advice!

Nyall
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Concerns re UX of new "duplicate features" actions in 2.99

Régis Haubourg
Hey, for reference purpose, reviewing the issues  there is already a feature request about action visibility here
https://issues.qgis.org/issues/17581
Regards
Régis

2018-02-22 0:01 GMT+01:00 Nyall Dawson <[hidden email]>:
On 22 February 2018 at 07:15, David Signer <[hidden email]> wrote:
> Hi Nyall
>
> It's okay for me, when you merge it to be save and we remove it, when the
> issue is resolved.
>
> But I'll remove the part that the duplicate functions toggles the edit mode
> anyway.
> So in case there will be still the action to duplicate on a not editable
> layer somewhere (what it shouldn't) it won't damage the layer.

Thank you -- merged. Happy to help with the rework if you need advice!

Nyall
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer