Взаимодействие посредством email; этапы разработки GUI-приложения

Неверное утверждение

«Git не подразумевает канала обмена информацией»

Потому что email.

Git и почта

• Повторение: git-format-patch → передача патчей → git-am

Немного про почту

• обмен сообщениями: SMTP и STMP+SSL
  • Oldschool-почта
• доступ к почтовым ящикам: IMAP (POP3, …)
• Современная почта:

  • понятие «почтовый клиент» (TODO запилить опрос в ТГ ☺)

• Списки рассылки

Что нужно для Git

Инструкция от sourcehut

• CLI: отправка (нам достаточно настроить git-send-email)

• CLI: получение

  • (с помощью Imap-CLI реализовать не удалось)

  • Т. е. реально проще скопипастить

  • Исключение: sourcehut формирует URL, пригодный для скачивания, после чего достаточно любой утилиты,

    • например curl

    • или (извините)

         1  python3 -c 'import sys; import urllib.request; sys.stdout.buffer.write(urllib.request.urlopen("https://down.lo.ad/url").read())'   
      

• WEB-почта (git format patch → передача патчей → git am)

• подписи

Взаимодействие и информационное пространство

На примере sourcehut, чтобы отличить то, что присуще Git от инициатив GutHub-а.

Что нужно помимо git?

• Статическое инфопространство:

  • Wiki/CMS прямо в репозитории

  • странички для сайтогенераторов (типа getpelican.com)

• Общение/обмен информацией:

  • Списки рассылки

    • Разделение на информационные списки и devel-списки для обмена патчсетами

  • Сниппеты

• Обработка ошибок, планирование работ

  • Багтреккеры

А ещё есть CI, но он требует ресурсов и либо свой, либо платный

Пример sourcehut показывает, что

• Все изменения можно выполнять, формировать и применять локально, а инфоканал служит только инструментов передачи

• Всё взаимодействие также выполнять через почту, при наличии списка рассылки (статических, для подписавшихся, или динамических, для обсуждения ошибок)

Отличие GhiHub, BitBucket, GitLab и прочего:

• Информационные каналы способ их использования привязан к движкам сайтов
  • Merge request vs. pull request vs. что-то ещё

Tkinter и не только

Чего не было сказано про tkinter:

• Меню, в том числе контекстные

• Всякие иные виджеты

• ttk (см. также tkinter.ttk) — поддержка тем

• прочее…]

Что вместо tkinter?

• PyQt, PyGtk, WxPython, Kiwy, …

• (Внезапно!) Brython, Питон, написанный на JS + доступ к DOM броузера

  • Пример кода на brython

Этапы разработки (GUI?) приложения

0. Интерфейсная модель

   • Как будут выглядеть составные части проекта, и что они должны делать с точки зрения пользователя

     • Пользователь — это тот, кто пользуется вашим проектом (т. е. если вы пишете библиотеку, то пользователь — это программист, и интерфейс — это API)

     • В случае сложной модели рекомендуется делать скетчи типа «нажал туда-то показалось то-то, в результате изменилось вот это»
     • Стараться не формулировать постановку задачи в терминах инструментов её решения (т. е. не говорить про события, обработчики, переменные, типы данных и т. п.)
   • Хоть на бумажке (чаще всего самый быстрый способ)

   • Но можно и Pygubu или картинки в чём-то вроде Dia

1. Заглушки — фиксируют место в коде, позволяют трассировать
2. Реализация
   • Имеет смысл разделять логику и интерфейс, в т. ч. для тестов

   • MVC и ему подобные

     • Например, пользователь нажал кнопку «Execute»: обработчик кнопки не обязана знать, какое именно действие при этом нужно выполнить, а само действие — о том, что оно выполняется именно по кнопке «Execute»
   • Пример (если получится простой)

     TODO: доделать это: https://git.sr.ht/~frbrgeorge/GradeProject2021

Д/З

TODO