D27338: Provide an initial implementation for input-method-unstable-v1
Vlad Zahorodnii
noreply at phabricator.kde.org
Thu Mar 26 07:52:01 GMT 2020
zzag added inline comments.
INLINE COMMENTS
> inputmethod_interface.cpp:128-129
> + wl_resource_destroy(resource->handle);
> + if (resourceMap().isEmpty())
> + q->deleteLater();
> + }
Destroy `q` in zwp_input_method_context_v1_destroy_resource(). In the destructor request, we usually want to destroy only the resource.
> inputmethod_interface.cpp:181
> +
> +class Q_DECL_HIDDEN InputPanelSurfaceInterface::Private : public QtWaylandServer::zwp_input_panel_surface_v1
> +{
We need to destroy the wl_resource for zwp_input_panel_surface_v1 when the associated surface is destroyed.
> apol wrote in inputmethod_interface.cpp:179
> I don't know, just looked at it and it doesn't seem that useful?
zwp_input_panel_surface_v1 defines a surface role (based on weston code) so it should be a subclass of SurfaceRole. In long term, we want to do something like
SurfaceRole *role = SurfaceRole::get(surface);
if (role) {
wl_resource_post_error(resource->handle, ZMY_SHELL_SURFACE_ERROR_ROLE,
"Cannot reassign surface role"); // DIE!
return;
}
> apol wrote in inputmethod_interface.cpp:199-200
> I would rather not, otherwise when implementing private members they read like local variables.
Frameworks' policies have no a single word about this so I guess it's okay(?) to put `m_`. I asked to drop `m_` because Qt folks seem to prefer not to put `m_` in private classes.
I would appreciate if you bring this topic up to the discussion in #kde-frameworks-devel since we're not consistent with naming in private classes.
REPOSITORY
R127 KWayland
REVISION DETAIL
https://phabricator.kde.org/D27338
To: apol, #kwin, #frameworks
Cc: zzag, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200326/7c429c3b/attachment-0001.html>
More information about the Kde-frameworks-devel
mailing list