Bug 425591

Summary: share tab bricked in master
Product: [Frameworks and Libraries] kdenetwork-filesharing Reporter: Harald Sitter <sitter>
Component: generalAssignee: Harald Sitter <sitter>
Status: RESOLVED FIXED    
Severity: normal CC: nate
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In: 20.12
Sentry Crash Report:

Description Harald Sitter 2020-08-20 13:13:39 UTC
trying to edit shares more than once falls over with current master because the qml types are registered as singleton types. that falls over impressively when opening multiple properties tabs as any after the first will fall over the now nullptr'd singletons.

needs reshuffling to contextProperty() on the engine. super invasive though, so pending mrs need landing first
Comment 1 Bug Janitor Service 2020-08-21 11:44:48 UTC
A possibly relevant merge request was started @ https://invent.kde.org/network/kdenetwork-filesharing/-/merge_requests/6
Comment 2 Harald Sitter 2020-08-21 19:17:07 UTC
Git commit c01860e597362b0ecae059480b4591e509c2de1d by Harald Sitter.
Committed on 21/08/2020 at 11:44.
Pushed by sitter into branch 'master'.

fix multiple opening of properties

in the qml port I incorrectly registered the cpp types as singletons,
but from a registration POV (which is application-wide) they aren't
singleton. they are bound to the context of the plugin instance that
created them. alas, this is a bit awkward to present because none of the
classes can deal with post-ctor initialization (that is: qml would ctor
the objects and then configure them through the properties) so we can't
use them through QML directly. we could construct them per-engine with
the qmlRegisterSingletonType callback system, but that's a bit tricky
because Model, UserManager and ShareContext are tightly related, so we'd
have to do extra fiddeling to get them to link up.

instead simply expose these three as properties on the plugin and set
the plugin as contextproperty. longer-term it may be worthwhile to
change the three classes to support qml-style property construction so
we can construct them from QML as that would then also resolve some
asyncness concerns I had about the fact that the ctors are doing data
processing (even though it is very lightweight data).

this also makes the root widget of the page a unique_ptr. because of the
child ordering here the widget is actually a sibling of the plugin
instance so it can and will get deleted after the plugin which results
in bogus warnings as the context property (the plugin) gets destroyed
and all bindings get reevaluated against the now null property
FIXED-IN: 20.12

M  +15   -15   samba/filepropertiesplugin/qml/ACLPage.qml
M  +16   -15   samba/filepropertiesplugin/qml/InstallPage.qml
M  +3    -1    samba/filepropertiesplugin/qml/RebootPage.qml
M  +2    -2    samba/filepropertiesplugin/qml/UserPage.qml
M  +4    -4    samba/filepropertiesplugin/qml/main.qml
M  +19   -13   samba/filepropertiesplugin/sambausershareplugin.cpp
M  +11   -0    samba/filepropertiesplugin/sambausershareplugin.h

https://invent.kde.org/network/kdenetwork-filesharing/commit/c01860e597362b0ecae059480b4591e509c2de1d