1. 07 May, 2020 1 commit
  2. 03 May, 2020 1 commit
  3. 01 May, 2020 1 commit
  4. 24 Apr, 2020 4 commits
    • Nicolas Fella's avatar
      Implement basic device type detection · 9277cc53
      Nicolas Fella authored
    • Simon Redman's avatar
      [SMS App] Convert tabs to 2 spaces in ChatMessage.qml · 95a62f4f
      Simon Redman authored
      How did those get there?
    • Jiří Wolker's avatar
      [SMS App] Make SMS message field scrollable · 2ef5cd45
      Jiří Wolker authored
      ## Summary
      This patch makes SMS message field scrollable and limits its height to ⅓
      of window height (or ⅔ for smaller windows) so messages in conversation
      are shown even when writing very long messages.
      ## Test Plan (and screenshots)
      <small>These screenshots are in APNG and WEBP formats. Download them if
      your browser does not support this format.</small>
      ### Before:
      Message field height was not limited. Message field could be even higher
      than window. That makes first lines of this field and messages in
      conversation inaccessible.
      ### After:
      Message field height is limited to ⅓ or ⅔ of window height. When text
      content reaches this threshold, scroll bars will show up.
    • Jiří Wolker's avatar
      [SMS App] Make SMS character counter width only grow · 6abe790a
      Jiří Wolker authored
      SMS character counter was changing its width (both growing and
      shrinking) so it also resized message field (and that caused text
      reflow). This patch makes counter width only grow.
      Type SMS that is long enough to make SMS character counter wider than
      “Send” button. Remove the text (leave there 150 or 60 chars to keep it
      visible). Character counter should keep its width.
  5. 23 Apr, 2020 13 commits
  6. 22 Apr, 2020 2 commits
  7. 16 Apr, 2020 6 commits
  8. 15 Apr, 2020 1 commit
  9. 13 Apr, 2020 1 commit
    • Philip Cohn-Cort's avatar
      Finally, we have support for sending out Battery information. · c315170b
      Philip Cohn-Cort authored
      ## Summary
      The core idea is as follows:
      1. When a Link loads the BatteryPlugin, we query Solid for a list of batteries.
          1. If the list is empty, we print a warning message and return quickly
          2. Otherwise, we connect *two signals* to every object in that list
      2. We send out a single new NetworkPacket as soon as we've processed that list
      3. When either of those two signals emits, we send another new NetworkPacket
      ### Multi-battery Support
      BUG: 357193
      To handle devices with multiple batteries (requested in that bug), we average
      together the battery percentages. This also includes a new field in the packet for
      'number of batteries' called `batteryQuantity`. For backwards compatibility, we can
      assume it has a default value of one.
      This should ensure we support
      - devices with no batteries at all (like many desktop machines)
      - devices with hot-pluggable batteries (like those laptops with detachable screens)
      ### Concerns
      Note that the implementation isn't perfect.
      We'll need some new localizable text to make it clear that we now support sending
      battery status information.
      Then there's a rather significant question: maybe we should have two battery plugins
      on each client, like we do for the `findmyphone`/`findthisdevice` plugins?
      ## Test Plan
      We need to ensure that other clients (including those using the Android codebase)
      will respond correctly. The main things to look at are
      1. are these new packets sent when the plugin is enabled, and not sent when it's disabled?
      2. is the charge percentage accurate?
      3. is the charge state (charging, discharging, or full) accurate?
      4. do we see the correct number of warnings for low-battery?
  10. 12 Apr, 2020 1 commit
  11. 10 Apr, 2020 2 commits
  12. 09 Apr, 2020 4 commits
  13. 08 Apr, 2020 3 commits