You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In case of showing a vertex, the inspector should habe an additional section (like all relations section) listing all connected ways:
When clicking a way there,
the way is made the way to stay on in view of vertex navigation,
the associated halo is shown, which makes identifying the way easier not only for vertex navigation,
a toolbar is shown below the way to stay on in the list.
The toolbar offers operations on the specific pair of vertex and way.
Some ideas are:
Jump to way, which would offer access to coincident ways
Delete vertex from way
Disconnect: Same as above, but replace it by a new vertex in the same position
Jump to first/last/next/previous vertex, as a graphical equivalent of the vertex navigation keys, making the discoverable.
Continue way, this might remain a duclicate to the radial menu operation, but accessing from this toolbar might be easier in dense environments of the vertex, and especially in case of coincidence.
The impact on the user interface would be small, because it does effect the inspector in the case of a vertex only, where typically very few information has to be displayed. In addition the connected ways section can be shown collapsed by default in most cases, but should be automatically unfolded where coincidence exist, or where unconnected ways are around in an invisible short distance. This can make users aware of the specific situation.
@bhousel If the impact on the UI is still deemed to be too complex let's find a way to make it available for the intermediate users as a task or plugin. I this case I hope you will change your mind in view of complexity when testing the final code.
If it is acceptable, I will try to make my first pull request. I think this is a good issue to start with because I expect to find examples for most required things in the existing code. I might need some help later, but I have already found the relevant sources and I managed to insert a second raw membership editor as an exercise and preparation for this issue.
The text was updated successfully, but these errors were encountered:
This seems ok to add something like an "All Parents" section, down near where the relation membership UI would go.
Being able to see the parents of a vertex and select it from the list (the same way parent relations work) seems simple enough. You could probably add next/previous/first/last somehow too. You might be able to make a textual stripmap that shows where the current vertex sits along the way in context with these other vertices - kind of like the digital map we have in some of our subways in nyc:
I am unsure about adding operations there. I kind of think adding stuff like "Disconnect", "Delete", "Continue" might be be too much.
In case of showing a vertex, the inspector should habe an additional section (like all relations section) listing all connected ways:
When clicking a way there,
The toolbar offers operations on the specific pair of vertex and way.
Some ideas are:
Jump to way
, which would offer access to coincident waysDelete vertex from way
Disconnect
: Same as above, but replace it by a new vertex in the same positionJump to first/last/next/previous vertex
, as a graphical equivalent of the vertex navigation keys, making the discoverable.Continue way
, this might remain a duclicate to the radial menu operation, but accessing from this toolbar might be easier in dense environments of the vertex, and especially in case of coincidence.The impact on the user interface would be small, because it does effect the inspector in the case of a vertex only, where typically very few information has to be displayed. In addition the connected ways section can be shown collapsed by default in most cases, but should be automatically unfolded where coincidence exist, or where unconnected ways are around in an invisible short distance. This can make users aware of the specific situation.
@bhousel If the impact on the UI is still deemed to be too complex let's find a way to make it available for the intermediate users as a task or plugin. I this case I hope you will change your mind in view of complexity when testing the final code.
If it is acceptable, I will try to make my first pull request. I think this is a good issue to start with because I expect to find examples for most required things in the existing code. I might need some help later, but I have already found the relevant sources and I managed to insert a second raw membership editor as an exercise and preparation for this issue.
The text was updated successfully, but these errors were encountered: