1. 07 Aug, 2019 1 commit
  2. 29 Jun, 2019 1 commit
  3. 26 May, 2019 1 commit
  4. 22 Apr, 2019 1 commit
  5. 24 Mar, 2019 1 commit
  6. 09 Jan, 2019 1 commit
  7. 24 Oct, 2018 1 commit
  8. 21 Jun, 2018 1 commit
  9. 18 Jun, 2018 1 commit
  10. 12 May, 2018 1 commit
    • Nicolas Fella's avatar
      Enable desktop2desktop keyboard input · 3c4aa590
      Nicolas Fella authored
      Summary:
      Fixes T6701
      
      The reason it did not work before is that the "Keyboard" did not report itself as available.
      
      Test Plan:
      Type in plasmoid on one Desktop, see text on another.
      Note that no ack packets are sent, so the text does not appear in the original input text field. I want to await the discussion in D12670 before doing that
      
      Reviewers: apol
      
      Reviewed By: apol
      
      Subscribers: mtijink, kdeconnect
      
      Tags: #kde_connect
      
      Maniphest Tasks: T6701
      
      Differential Revision: https://phabricator.kde.org/D12812
      3c4aa590
  11. 17 Mar, 2018 1 commit
  12. 05 Mar, 2018 1 commit
  13. 13 Oct, 2017 1 commit
  14. 19 Sep, 2017 1 commit
  15. 04 Sep, 2017 1 commit
  16. 03 Sep, 2017 1 commit
    • Jean Vincent's avatar
      Make member variable names, & placement and * placement more coherent · 72535ecf
      Jean Vincent authored
      Summary:
      Change all member variables to the form m_fooBar because it is the preferred form in Qt (it was half and half between this and mFooBar, and a minority didn't have anything).
      Place all references and pointers on the side of the type since it is the majority.
      
      Basically:
       - mFoo -> m_foo
       - foo -> m_foo (if it is a member variable)
       - Type &ref -> Type& ref
       - Type *ptr -> Type* ptr
      
      Reviewers: #kde_connect, nicolasfella, albertvaka
      
      Reviewed By: #kde_connect, nicolasfella, albertvaka
      
      Subscribers: albertvaka, #kde_connect
      
      Tags: #kde_connect
      
      Differential Revision: https://phabricator.kde.org/D7312
      72535ecf
  17. 06 Aug, 2017 2 commits
  18. 14 Jul, 2017 1 commit
  19. 13 Jun, 2017 1 commit
  20. 08 Jun, 2017 1 commit
  21. 27 May, 2017 2 commits
  22. 09 Apr, 2017 2 commits
  23. 11 Jan, 2017 1 commit
  24. 10 Jan, 2017 1 commit
    • Holger Kaelberer's avatar
      kdeconnect-kde: Add remotekeyboard plugin · 040ad735
      Holger Kaelberer authored
      Allow to inject keypress events to remote peers (most notably Android devices)
      
      Notes / open issues / possible improvements:
      
      - For the json-payload I used the syntax of the key-events as sent by mousepad-plugin with the addition of a "sendAck"-flag. If "sendAck" is set to true the remote peer should echo a key-event if it could be handled, thus allowing the local client to find out whether the key was accepted. For performance reasons, it's allowed to send multi-char strings in the "key" property (performs much better if you send a whole string via "echo '...' |  kdeconnect-cli ..." e.g.)
      
      - kdeconnect-cli: For now takes a string and transforms it into single key-events for visible characters only. In a first implementation I used a kbhit() helper that used termios.h to catch and relay keypresses interactively (including some special-events), which was not optimal. A better approch might be to use linux input-api directly. Would this be an option regarding cross-platform compatibility or can I assume to develop for Linux only? Being a command-line guy, I'd really like to have a fully featured kdeconnect-cli interface ;-)
      
      - Factor out the Qt::Key-to-internal keymap to some core-helper because it corresponds to the mapping in the mousepad-plugin?
      
      - The plasmoid is not perfect as it is: A single line containing a non-echoing TextField (i.e. it eats all the KeyPress events), and only ack-ed keypress-packets from the peer device are injected if they contain visible keys. Advantage: the user sees whether his key-presses are accepted by the peer device. Disadvantage: The echoed text does not correspond 1:1 to what is shown on the peer's display, user might be confused when typing without success. I played around with different variations each of which with its proper shortcomings:
      1. An echoing Textfield for typing: Has the advantage that the user can directly see what he is typing, which makes interaction in the typing field easier, BUT messes up interaction if the Editor on the peer is changed silently and does not notify the user if his keypresses are not handled by the peer.
      2. A non-echoing TextField for typing PLUS a readonly one for printing visible echoed keys. Disadvantage: same as for the previous one and uses more space on the plasmoid.
      Comments? Ideas?
      
      REVIEW: 129727
      BUG: 370919
      040ad735
  25. 20 Dec, 2016 1 commit
  26. 02 Dec, 2016 2 commits
  27. 30 Nov, 2016 1 commit
  28. 25 Nov, 2016 1 commit
  29. 24 Nov, 2016 1 commit
  30. 19 Oct, 2016 1 commit
  31. 11 Oct, 2016 2 commits
  32. 30 Sep, 2016 1 commit
  33. 29 Sep, 2016 1 commit
  34. 28 Sep, 2016 1 commit
  35. 18 Sep, 2016 1 commit