Join node to way should operate on all selected nodes

[martin.zdila@…]

Join node to way should operate on all selected nodes. Please check my patch. Not sure if it is the best approach but it works and also obeys the undo buffer.

[martin.zdila@…]

the patch

[bastiK]

Patch looks ugly, are you sure it has to be done like that?

[martin.zdila@…]

What's your problem with it? Do you have any better solution already? Next time I'll only report the issue and leave my ugly patches for my own. Good luck.

[bastiK]

Sorry for the rude language, it wasn't my intention to offend you.

It's a weakness of the current undo/redo system, that you cannot build on previous commands and still keep it grouped in one SequenceCommand, it has to be done "in one go". So rather than calling executeCommand(), I would suggest to compile the final list of way nodes directly. Then, one ChangeCommand for each way will be enough.

[martin.zdila@…]

Replying to bastiK:

Sorry for the rude language, it wasn't my intention to offend you.

Offending my code offends me ;-)

It's a weakness of the current undo/redo system, that you cannot build on previous commands and still keep it grouped in one SequenceCommand, it has to be done "in one go".

This is exactly why I "hacked" (extended) SequenceCommand.

So rather than calling executeCommand(), I would suggest to compile the final list of way nodes directly. Then, one ChangeCommand for each way will be enough.

This was my first implementation. It was almost working, but the problem was that if there were multiple nodes joined to the same way segment, then their order was non-deterministic. I believe this is possible to solve too, but it is still much more difficult than my first "hacky" solution that emulates something like "transactions"...

I think it would be good to have something like a "transaction system", where it would be possible to submit changes in any phase of the process so that subsequent operations within same transaction would work on data modified by previous operation. Afterwards the transaction would be commited or rolled back. The commit would also represent one undo unit.

This could maybe make even more algorithms simpler because they could then drop the part that collects changes made by previous steps of the whole action to finally create consistent changes.

In any case I can still (try) to re-implement it to the way you suggest if this feature is desired (for me it is). What do you think?

[bastiK]

Replying to martin.zdila@…:

Replying to bastiK:
This was my first implementation. It was almost working, but the problem was that if there were multiple nodes joined to the same way segment, then their order was non-deterministic. I believe this is possible to solve too, but it is still much more difficult than my first "hacky" solution that emulates something like "transactions"...

I think it would be good to have something like a "transaction system", where it would be possible to submit changes in any phase of the process so that subsequent operations within same transaction would work on data modified by previous operation. Afterwards the transaction would be commited or rolled back. The commit would also represent one undo unit.

This could maybe make even more algorithms simpler because they could then drop the part that collects changes made by previous steps of the whole action to finally create consistent changes.

In any case I can still (try) to re-implement it to the way you suggest if this feature is desired (for me it is). What do you think?

I'd say it would be an improvement and the feature is welcome. You can either do it "oldschool" or it might really be a good idea to extend the undo/redo system. In this case you probably have to keep in mind multithreading, so different "execution sequences" don't get interleaved in an unpredictable way.

[Don-vip]

Ticket #7897 has been marked as a duplicate of this ticket.