Mudlet: moving scripts & folders deletes others

[Kebap]

Brief summary of issue / Description of requested feature:

Steps to reproduce the issue / Reasons for adding feature:

1. Drag any item onto folder or right above / beneath a folder to move it to an adjacent position
2. The item will arrive at its destination alright
3. The last other item inside that folder will be deleted

Error output / Expected result of feature

1. Other items should never be affected

Extra information, such as Mudlet version, operating system and ideas for how to solve / implement:

Noted in Win10, Mudlet PTB 2020-11-25-b33b6
Whereas Mudlet release version 4.10.1 still works fine

[vadi2]

Yes, big one. Does this happen with real items as well, or just the blank 'New Triggers'?

[Kebap]

Indeed it does. That's how I noticed it.. 😢

This is just a small concise example for your comparison.

Also I noted other shenanigans in some cases only some (but not all) of the moved items will reappear after closing and opening the profile. Whereas reopening the script editor won't suffice.

Another maybe related follow-up error I noticed is copy/paste broke as well in that, if I copy script A from sub folder B/C and want to paste it into sub folder D/E, instead it will move the target folder into the original folder and paste the script there like B/C/D/E/A

Looking through recent commits, there are few touching this area of code.
Looking where to fetch compiled versions of recent development for cross comparison to narrow it down..

[vadi2]

I've git bisected it to b33b6c8dc3928a6aaa2fcc6ae182e54ec89b5768. @SlySven, could you look at fixing?

[SlySven]

Can I reopen this - the PR/Commit that has been judged to be the guilty party didn't seem possible to be the perpetrator - AFAICT.

However, given the nature of the failures I suspect it is the removal of the first one of the pair of methods:

• (void) TTreeWidget::rowsAboutToBeRemoved(const QModelIndex& parent, int start, int end)
• (void) TTreeWidget::beginInsertRows(const QModelIndex& parent, int first, int last)

(The second one is empty of actual code and is a dummy)

The odd thing is that these methods are defined - but do not appear to be called from anywhere - which is why I thought it was okay to excise them...

... however, given that Qt documents (void) QTreeWidget::rowsAboutToBeRemoved(const QModelIndex& parent, int start, int end) as [override virtual protected] I am getting a nasty feeling that I am being bitten by a C++ feature that has caught me unawares!

[Kebap]

Well yeah, resubmit without these very changes, then we can test again.

Maybe add a link here as a brief comment why we do need the empty function.

[SlySven]

Okay, can we check that the replacement for the borked PR #4383 i.e. #4415 does NOT display this problem/bug...?

Maybe add a link here as a brief comment why we do need the empty function.

Having gotten my fingers burnt I am just putting it back and leaving it be...!

[Kebap]

After merging 4415, this bug still didn't return. Hooray!