Refactor/neon/dialogs

[Leptopoda]

Fixes: #995
Fixes: #535

I moved the folder dialogs (create, rename, delete) into the framework as this can be reused in many clients.

[provokateurin]

I do not agree with the move to put app implementation specific dialogs into the framework. If we want to support this then it should be done through the interface abstractions.
I'm sorry, but I think you will need to revert large parts of the PR.

[Leptopoda]

I guess you mean the folder dialogs?
I agree that the framework shouldn't hold client specific code but I also argue that the concept of folders (or labels/categories as they are called on notes) is a concept many apps need. I think that they should be reused.
I can pick it apart again. And we can discuss this in a separate issue.

Can you please provide feedback to the design (as I think it changed for every dialog).
Similarly a rough review of packages/neon/neon/lib/src/widgets/dialog.dart would be great to know wether the widgets are good enough.

[provokateurin]

I like the design a lot ❤️

I found some places that need to be improved:

I haven't tested all the dialogs yet, but most of them look very good!

[Leptopoda]

@provokateurin ping :)

[provokateurin]

Looks pretty good to me, although I still found some problems:
Opening the copy/move dialogs throws Bad state: Snapshot has neither data nor error and nothing is shown (this might already be the case on the main branch as well, I rebased this branch locally before testing).

[provokateurin]

I checked the move/copy dialogs on the main branch and there they work, so it's definitely a regression of these changes.

[provokateurin]

Btw can you maybe also fix #1220 since you are already touch that part of the code?

[Leptopoda]

Btw can you maybe also fix #1220 since you are already touch that part of the code?

Sure. I'll take a look

[Leptopoda]

just a rebase for now.

[provokateurin]

Tests LGTM, I'll give it another round of tests to check that everything works correctly.

[provokateurin]

From my testing:

• Moving a file or folder has the file or folder set as the initial path. For folders this makes no sense and for files even less. The parent dir should be the initial path.
• Instead of greying out the choose button when trying to move a directory into itself the whole entry should just be hidden in the listing. This completely avoids the problem.
• Copying a folder into itself should still be possible (even though it is a weird use-case).

Everything else worked flawlessly ❤️

[Leptopoda]

Copying a folder into itself should still be possible (even though it is a weird use-case).

Why? This sounds like it should just break

[provokateurin]

It is not a problem because the original folder still exists. You are only creating new files, not moving which is deleting and re-adding them which requires the folder to still exist while it doesn't

[Leptopoda]

Trying to copy a folder into itself returns in a 409 and an error message being shown
[13] [Fri Dec 29 18:23:03 2023] 172.17.0.1:49316 [409]: COPY /remote.php/webdav/Notizen
[13] [Fri Dec 29 18:23:03 2023] 172.17.0.1:49316 Closing

[provokateurin]

Ok, then not special handling 👍

[provokateurin]

LGTM, I think some of the logic for showing modals and bottom sheets could be moved from files into the framework so it can be reused, but that can be done later when needed.