pidgin/nest

Fix a couple typos in the design guidelines.

2019-02-03, John Bailey
ba5f60fccca8
Parents b73b0094e4c6
Children 2ba023209eea
Fix a couple typos in the design guidelines.
1 files changed, 2 insertions(+), 2 deletions(-)
  • +2 -2
    hugo/content/development/design-guidelines.md
    • --- a/hugo/content/development/design-guidelines.md Sun Feb 03 19:50:52 2019 -0500
    +++ b/hugo/content/development/design-guidelines.md Sun Feb 03 20:47:09 2019 -0500
    @@ -14,7 +14,7 @@
    The workflow in Pidgin is intended to be "I would like to chat with Sean about wibbles", not "I would like to create an XMPP conversation with seanegan@pidgin.im".
    -The focus is on the goal, not the process. In reaching toward this focus, we have chosen to paper over the differences between the various protocols and features as much as possible (without crippling or needlessly complicating things). This has lead to decisions such as the removal of protocol icons from the buddy list and the implementation of contact-aware chats and logs.
    +The focus is on the goal, not the process. In reaching toward this focus, we have chosen to paper over the differences between the various protocols and features as much as possible (without crippling or needlessly complicating things). This has led to decisions such as the removal of protocol icons from the buddy list and the implementation of contact-aware chats and logs.
    ## Simpler Is Better
    @@ -33,7 +33,7 @@
    We do not want massive amounts of very similar code in libpurple, so the implementation of file transfer at the libpurple level has to abstract away from how individual protocols handle it, so as to be able to use the same calls from all file transfer supporting protocols.
    -Last, but not least, before the user can actually send or receive a file, the UI (Pidgin, Finch, or Adium) must support it. These interfaces know nothing about the protocol, and have only limited contact with the core. This helps to enforce the desire for uniformity explained above. It also makes it easier for the only sort of duplication we encourage: many interfaces. The core implementation cannot assume too much about what the UI will do, because the GTK+ UI (Pidgin) might need to handle a file transfer somewhat differently than the ncurses based UI (Finch).
    +Last, but not least, before the user can actually send or receive a file, the UI (Pidgin, Finch, or Adium) must support it. These interfaces know nothing about the protocol, and have only limited contact with the core. This helps to enforce the desire for uniformity explained above. It also makes it easier for the only sort of duplication we encourage: many interfaces. The core implementation cannot assume too much about what the UI will do, because the GTK+ UI (Pidgin) might need to handle a file transfer somewhat differently than the ncurses-based UI (Finch).
    Patches that voilate this layering will be rejected. In practice, this means that there is more work involved to introduce a new class of functionality, say file transfer, white-boarding, voice, or video. On the other hand, it means less work to implement any given class of functionality for a new protocol or for a new UI.