D11773: New plugin: Find this device

Sat Mar 31 14:06:50 UTC 2018

kossebau added a comment.

  In D11773#237073 <https://phabricator.kde.org/D11773#237073>, @sredman wrote:

  > In D11773#237062 <https://phabricator.kde.org/D11773#237062>, @mtijink wrote:
  >
  > > Why wouldn't you want to ability to find a device? It'll never hurt you if you don't use it, and it gives you less plugins in the list.
  > >
  > > And if you don't want someone to be able to find a phone, why would you even connect? That doesn't make sense.
  >
  >
  > I think the usecase described by @kossebau makes sense: Mom and Dad have paired with their 10 year old kid's Android device and want to be able to find that device when it falls behind the sofa but don't want the kid to be able to make their computers ring whenever they tell him he can't have a cookie. Being able to switch on Find my Phone but switch off Find this Device makes sense.

  @mtijink I agree with you it makes little/no sense for devices which all belong to the same person and only accessible to them.
  But IMHO kdeconnect also offers solutions to use cases involving devices used by many different persons, at which point you want to have more tight control whom's device (or the group of people having access to it with the given login) can do what to your own device or someone elses.
  And the device (re)discover feature would be one where I, based on real life stories both in families and work, can see that one want to have selective control about which devices/users can explore the location of which other devices/users. Nothing everyone needs, but those who do will find it good to have, as otherwise the complete feature is no-go. And supporting those by a separate toggle should not hurt the rest too much. But see also braindump about plugin/features in general below, seems to me this is rather an example for a principle challenge yet to be solved.

  > Maybe the same usecase be achieved by having settings switches in the Plasmoid so that you could disable a device from being found by another device rather than having two separate plugins?

  Raises these questions with me:

  - where would people look to disable/enable a feature? what features do they map to plugins, so expect toggles at that level, what do they expect at other
  - is this something people want to toggle on/off often, so it needs to be more quickly to reach?

  Doing this as separate plugin has been for now rather pragmatic, it gave an UI option to toggle the service for free, no need to write a custom config (for now for the plasmoid, but also any future platform specific UI).

  I also understand the desire to keep the plugin list short, for the need of simple overview. Just, given kdeconnect is plugin-based by nature, if people go crazy and write lots of different plugins for different features (which is a goal,. no?), this desire cannot be fulfilled by principle, once the number of plugins outgrows 7 or whatever number people can manage in their mind at the same time. And the plugin managing UI needs some means to deal with this anyway (like having tags or at least group plugins by categories).
  So keeping the actual number of plugins low might be less a criteria than how to provide people a simple consistent UI concept, so they can quickly setup/configure all the services provided to (an)other device(s) and services used from (an)other device(s).

  From my own experiments so far (with developer mind, but also user one), I actually would like a kdeconnect configuration UI which is less driven by the technical idea of plugins, but more of (my?) mental model of services/features provided _to_ another device and used _from_ another device, where the client-server model matches, and then peer2peer ones, where the feature is bidirectional, like chat.

  Currently for things like sharing clipboard, notifications, data/files, etc., one has to read very precisely the description of a plugin to make sure if this plugin works in the correct direction. And for some features there are separate plugins per direction (like notifications), while for others there are  only single ones for both directions (like share).
  So while those plugins assumingly have been done based on most common use-case, ideally they would be generalized, so not-so-common use-cases can be covered as well.

  I have no opinion yet if this splitting by principle into server and client parts per features should be done by implementation and thus separate plugins, or rather only on the UI level. Needs some rethinking.

  Too much text already, but no time to cut it short, so just stopping the braindump here :) Guess this should be better moved into an own principal discussion? Would see to write an email to the mailinglist about this.

  In D11773#237092 <https://phabricator.kde.org/D11773#237092>, @nicolasfella wrote:

  > @kossebau If you have Telegram you might want to join our group https://t.me/joinchat/AOS6gA37orb2dZCLhqbZjg
  >  Hopefully we will have an IRC Bridge soon

  Thanks for invitation :) Not on telegram though, so will have to wait for IRC bridge.

REPOSITORY
  R224 KDE Connect

REVISION DETAIL
  https://phabricator.kde.org/D11773

To: kossebau, #kde_connect
Cc: sredman, mtijink, apol, nicolasfella, Danial0_0, krantideep95, adeen-s, SemperPeritus, ahmedbesbes, daniel.z.tg, jeanv, seebauer, bugzy, MayeulC, menasshock, ach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20180331/25090c36/attachment.html>