PySimpleGUI 기술 관련 소식

 (github.com/PySimpleGUI)
4P by GN⁺ | ★ favorite | 댓글 1개
  • PySimpleGUI는 상용화 시도를 마친 뒤 PySimpleGUI 5 코드에서 라이선스와 보안 구성요소를 제거하고, GitHub와 PyPI에 LGPL3 라이선스의 PySimpleGUI 6으로 다시 공개됨
  • 최신 버전은 python -m pip install PySimpleGUI로 설치할 수 있고, 이전 버전 4.60.5.1이나 GitHub의 master, 특정 릴리스 6.1도 pip로 직접 설치 가능함
  • PySimpleGUI는 tkinter 등 GUI 라이브러리의 래퍼로, GUI SDK를 더 단순하고 압축된 구조로 바꾸면서 세부 커스터마이징을 제공하며 사전 GUI 프로그래밍 경험이 필요 없다고 소개됨
  • 버전 6.2에는 Window.settings_save 버그 수정, Multiline 이미지 인라인 출력, psgupgrade, Tree 노드 프로그래밍 선택, Window.start_timer의 "H:M:S" 문자열 타이머, Frame 테두리 색상 설정 등이 포함됨
  • 프로젝트는 풀 리퀘스트를 받지 않는 방식으로 유지되며, 장기 미래는 불확실하지만 작성자는 코드 작성과 생태계 정리를 계속하겠다는 입장을 밝힘

PySimpleGUI 6의 재오픈소스화

  • PySimpleGUI는 상용화 시도를 했지만, 기대한 수준으로 프로젝트를 지속하는 데 필요한 자원을 만들지 못함
  • 2025년 2월 PySimpleSoft 종료와 2025년 말까지 지원 지속이 발표됐고, 이후 코드·문서·저장소를 어떻게 할지가 남은 문제였음
  • PySimpleGUI 5 코드는 라이선스와 보안 구성요소를 제거한 뒤 GitHub와 PyPI에 공개됨
  • 새 공개 버전은 LGPL3 라이선스를 사용함
  • Udemy 강의는 한동안 무료로 제공되며, 쿠폰 코드는 033334A16163C571B739임

설치 방법

  • PyPI 최신 버전 v6 설치:
    • python -m pip install PySimpleGUI
  • 이전 버전 4.60.5.1 설치:
    • python -m pip install PySimpleGUI==4.60.5.1
  • GitHub 저장소의 최신 코드는 직접 설치할 수 있음:
  • GitHub의 특정 릴리스를 설치하려면 master를 릴리스 번호로 바꿈:
  • 저장소를 클론하거나 다운로드한 뒤 로컬 설치도 가능함:
    • python -m pip install .

PySimpleGUI의 역할

  • PySimpleGUI는 tkinter와 다른 GUI 라이브러리를 감싸는 래퍼임
  • GUI SDK를 더 단순하고 압축된 구조로 바꾸면서도 세부 커스터마이징을 제공함
  • 사전 GUI 프로그래밍 경험이 필요 없다고 소개됨
  • README의 예제는 Text, Input, Button, Window, 이벤트 루프, window.read(), window.close()만으로 대화형 윈도우 앱을 구성함
  • 문서는 Docs.PySimpleGUI.com에 제공됨

개발 방식과 장기 전망

  • PySimpleGUI는 전통적인 오픈소스 프로젝트보다 독점 제품에 가까운 방식으로 개발돼 왔다고 설명됨
  • 풀 리퀘스트는 받지 않음
  • 장기적인 미래는 확실하지 않지만, 현재 작성자는 코드를 작성하고 도움을 주는 일을 즐기고 있음
  • PySimpleGUI 경험은 사람들이 만든 결과물을 볼 수 있었던 “once-in-a-lifetime” 경험이었다고 표현됨

버전 6.2의 기능과 수정

  • 6.2에는 Window.settings_save 버그 수정이 포함됨
  • Multiline 요소에서 이미지를 인라인으로 “print”하는 기능이 추가됨
  • 최신 유지보수 릴리스로 업그레이드하는 기능이 다시 PySimpleGUI에 내장됨
    • Home Window 또는 명령행 psgupgrade를 사용할 수 있음
    • 릴리스 노트를 보고 새 버전을 설치할 수 있음
  • Graph 이벤트가 write_event_value 이벤트를 받을 때 무한 루프에 들어가던 #5750 버그가 수정됨
    • 실시간 버튼 플래그를 지우는 방식으로 수정됨
    • 변경 범위가 Graph 요소 조건문에 한정돼 회귀 가능성은 작다고 적혀 있음
  • Tree.update에 select_node_keys 파라미터가 추가돼 트리 노드를 사용자 선택처럼 프로그래밍 방식으로 선택할 수 있음
  • Multiline의 echo_stdout_stderr 기능과 파라미터가 수정됨
    • stdout 또는 stderr를 해당 요소로 재라우팅한 경우에만 echo함
    • 이 기능이 직접 재라우팅을 수행하지는 않음
  • #6686 수정으로 Calendar chooser 버튼이 window.read 반환 시점에만 지워져야 할 필드를 지우던 문제가 해결됨
  • Home Window에 유지보수 릴리스 버전 번호가 표시되고 설치 버튼 위치가 이동됨
  • Window.start_timer 호출 시 "H:M:S" 문자열로 타이머를 지정할 수 있음
  • 스크롤 가능한 Column 요소에 가로 스크롤만 지원하는 기능이 추가됨
  • Frame 요소에는 border_color, border_width_no_relief 파라미터가 추가돼 테두리 색상을 설정할 수 있음
    • Frame 테두리 색상은 별도 설정이 없으면 텍스트 요소 색상을 기본값으로 사용함
  • 문서의 call reference 섹션은 6.2 릴리스에 맞게 업데이트됨

드래그 앤 드롭과 주변 프로젝트

  • 드래그 앤 드롭은 오랫동안 바랐던 기능이며, PySimpleGUI 코드 변경 없이 사용자 코드 공간에서 구현하는 방식이 발견됐다고 설명됨
  • psgdnd는 PySimpleGUI에 드래그 앤 드롭을 추가하는 새 패키지임
    • pip로 설치해 사용할 수 있음
    • 더 많은 정보와 예제는 해당 저장소에 있음
  • psgdnd 6.0.1은 PyPI에 릴리스됐고 Windows에서 동작함
  • GitHub의 6.0.2에는 Linux에 필요했던 수정이 포함됨
  • Mac 지원 상태는 아직 알 수 없음
  • PSGMicroPython 저장소에는 MicroPython 기반 마이크로컨트롤러와 인터페이스하는 코드가 추가됨
    • Raspberry Pi Pico와 ESP32에서 동작함
    • 다른 보드에서도 동작할 수 있음
    • 견고하거나 큰 프로젝트로 의도된 것은 아니며, 유용할 수 있는 코드라고 소개됨

PSGWeb 프로토타입

  • PSGWeb은 PySimpleGUI를 브라우저 창에서 실행하는 프로토타입임
  • 대부분의 데모 프로그램과 동작함
  • GitHub의 PySimpleGUI 애플리케이션 URL 앞에 psgweb.us를 붙이면 실행을 시도할 수 있음
  • PSGWeb은 더 큰 PSG 5 작업의 일부로 만들어졌지만 공개되지 않았음
  • 이 프로토타입을 릴리스하거나 확장할 계획은 없음

AI 사용에 대한 입장

  • 작성자는 LLM을 문서 검색과 요약, 오류 조회, 조사, 지식 획득에 사용함
  • LLM으로 코드를 작성하지 않음
  • 이유는 단순히 코드 작성 자체를 좋아하기 때문이라고 밝힘
  • 프로젝트를 풀 리퀘스트에 열지 않은 것도 다른 사람이 코드를 써주기보다 직접 코드를 쓰고 싶었기 때문이라고 설명함
  • PySimpleGUI가 AI 시대에도 관련성이 있는지에 대해, 매일 사람들이 PySimpleGUI를 발견하고 설치하며 한 명 이상이 쓰는 것만으로 충분하다고 봄
  • 작성자는 Windows 앱을 만들 때 PySimpleGUI 없이는 상상하기 어렵다고 말함
    • 최근 6502 브레드보드 컴퓨터 작업에서 Raspberry Pi Pico 두 대와 PySimpleGUI 앱으로 버스 분석기를 만들었다고 설명함
    • Windows에서 도구를 제어하는 프런트엔드 앱을 PySimpleGUI로 쉽게 만들 수 있었다고 함

프로젝트 역사와 자금 문제

  • PySimpleGUI는 2018년 미디어 플레이어 프로토타입용 GUI가 필요해 만든 일회성 코드에서 시작됨
  • 목표는 객체지향 GUI 프레임워크 경험 없이도 Tkinter를 더 선형적이고 직관적인 방식으로 감싸 빠르게 동작하게 하는 것이었음
  • 작성자는 Python이나 오픈소스 경험 없이 GitHub에 올렸고, 전통적인 오픈소스 프로젝트보다 스타트업처럼 접근함
  • 타임라인:
    • 2018년 7월: Version 1
    • 2019년 6월: Version 4
    • 2020년 1월: 자금 문제가 주요 우려가 됐고 상용화가 언급됨
    • 2020년 11월: Udemy 강의 발표와 공개 도움 요청 추가
    • 2021년 12월: 강의 출시
    • 2024년 2월: Version 5 상용 출시
    • 2026년 4월: Version 6
  • GitHub의 Announcements Issue는 프로젝트 기록을 남기는 블로그처럼 사용됐고, 1,700개 넘는 항목으로 커짐
  • 읽기 쉽도록 문서의 Announcements 2018-2024 탭에 스냅샷이 게시됨
  • 풀타임 오픈소스 작업은 즉각적이고 지속적인 재정 압박을 만들었음
  • 후원과 기부는 GitHub Sponsors, Buy Me a Coffee를 통해 최고점에도 월 약 150달러 수준이었음
  • 61개 레슨, 11.5시간 분량의 Udemy 강의는 초기에 잠시 월 약 2,000달러까지 갔지만 이후 100달러 미만으로 떨어짐
  • 두 방식 모두 프로젝트를 장기적으로 유지하기에 충분하지 않았음

상용화 결과와 라이선스 경험

  • Version 5의 유료 제품 출시는 갑작스러운 결정이 아니며, README와 공지에서 여러 해 동안 공개적으로 논의돼 왔음
  • 2024년 초 다른 선택지를 소진한 뒤 상용 버전이 출시됨
  • 목표는 장벽을 세우기보다 접근성을 유지하는 것이었음
  • 재정 지속 가능성 기준으로는 잘 되지 않았지만, 경험·학습·관계 기준으로는 가치가 있었다고 정리됨
  • 상용화 이후 대부분의 사용자를 잃지는 않았고 많은 회사가 계속 PySimpleGUI를 사용함
  • 문제는 회사들이 라이선스를 구매하도록 만드는 것이었음
  • 취미 사용자와 학생은 무료로 사용하고 회사는 비용을 내는 Hobbyist License가 선택됨
  • 실제로는 대다수 사용자가 자신을 취미 사용자로 식별함
  • 수만 명의 기업 사용자가 무료 티어로 등록했고, 대기업에서도 수백 명의 사용자가 있으면서 유료 라이선스는 소수인 경우가 드물지 않았음
  • 무료 옵션을 제공한 결정 자체는 후회하지 않는다고 밝힘
  • 개인적 결론은 Python 도구와 라이브러리는 무료여야 한다는 문화적 기대가 강하다는 것임
  • 가격이나 불만이 핵심 문제처럼 보이지 않았고, 사람들은 계속 PySimpleGUI를 사용했지만 비용을 낼 의무를 느끼지 않았다고 해석함
  • 명확한 라이선스 조건도 항상 행동을 바꾸지는 못했음

현재 라이선스

  • 저작권 표기는 Copyright 2018-2026 PySimpleGUI. All rights reserved.임
  • 현재 라이선스는 LGPL3임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 업무상 Jira에 작업 시간 기록을 해야 했는데, 웹사이트를 계속 열어두는 게 싫었고 작업 중인 이슈를 찾고, 시간 기록 링크를 찾고, 코멘트를 추가하는 과정도 느렸음
    내게 할당된 이슈 목록과 코멘트/작업 시간 추가 버튼이 있는 데스크톱 앱을 원했음. Tkinter로는 보기 좋게 만드는 데 한참 헤맸지만, PySimpleGUI를 발견한 뒤 Jira API 훅을 붙여 원하는 걸 만들 수 있었고, UI 개발을 배우기 좋은 프로젝트였음

    • Jira가 너무 보편적으로 느려서 많은 사람이 커스텀 도구로 우회하려는 것 같음
      친구도 한 직장에서 Jira 기본 작업용 내부 Qt 클라이언트를 만들었다고 했고, 나도 Jira로 작업 추적을 해야 했을 때 https://github.com/go-jira/jira를 이용해 콘솔 스크립트 여러 개로 변경 작업을 처리했음
    • 직장에서 Jira 시간 기록을 시작한다고 하길래 새 직장을 찾기 시작했음
    • 이 앱의 소스가 어딘가 공개돼 있는지 궁금함. 이번 주에 비슷한 걸 만들까 생각 중이라, 이미 있는 앱에 Jira 인스턴스만 지정할 수 있다면 정말 좋겠음
    • 이게 정말 UI 개발 학습인지 의문임. 더 까다로운 프로젝트로도 이어지거나 확장될 수 있는지 잘 모르겠음

  • 이런 GUI 프레임워크들이 정말 기대됨. 네이티브 데스크톱 경험은 웹뷰 조합보다 훨씬 낫고, PySimpleGUI의 단순화된 이벤트 루프와 다중 백엔드 접근은 실제로 새롭다고 봄
    다만 데이터 구조와 함수만 주면 그걸 조작할 만한 적당한 인터페이스를 자동으로 만들어주는 “자동 GUI”가 왜 더 많지 않은지 궁금함. 패널을 세로/가로로 둘지, 탭 인터페이스나 팝업으로 둘지 휴리스틱으로 고르면, CLI로는 너무 중첩되고 웹앱으로 만들기엔 너무 네이티브한 기능을 많이 열어줄 수 있음

    • 관심 있을 만한 프로젝트로, Gooey는 “거의 모든 Python 3 콘솔 프로그램을 한 줄로 GUI 앱으로 바꿔준다”고 함
      https://github.com/chriskiehl/Gooey
    • 2011년에 함수 인자를 기반으로 웹용 자동 폼 생성기를 만들었고, 최근에는 D 언어 기반 GUI 툴킷에서도 비슷한 걸 조금 해봤음
      구조체를 정의하고 dialog 함수에 넘기면 구조체 필드에 맞춰 대화상자를 자동 생성하고, 사용자가 OK를 누르면 콜백을 호출하게 만들 수 있음. 사용자 정의 속성으로 어떤 위젯을 쓸지도 지정할 수 있는데, 예를 들어 int에 @ControlledBy!VerticalSlider(0, 100)를 붙이면 숫자 입력칸 대신 0~100 슬라이더가 됨. 메뉴 함수에도 @menu("Search") Find(string text) { ... } 같은 식으로 붙여 메뉴와 대화상자를 자동 생성할 수 있고, 변경 이벤트마다 콜백을 호출하는 DataControllerWidget도 있음. 몇 년 전 관련 글도 썼지만 진행은 매우 느림: http://dpldocs.info/this-week-in-d/Blog.Posted_2020_11_02.ht...
      더 시간을 쓰고 싶을 만큼 흥미로운데, 본업에 쓸 일이 없어 주말에 코딩하고 싶을 때 조금씩만 하게 됨
    • 그 설명에 맞는 것으로 수십 년 전 Naked Objects라는 게 있었음. Java 쪽에 관심이 없어서 써보진 않았지만 유용해 보였음
    • Python에는 TraitsUI가 괜찮은 “자동 UI”였고, 지금도 그런 역할을 함

  • 예제 미감이 [0]처럼 90년대에서 그대로 가져온 것처럼 보임. 프로토타입이나 CLI를 못 쓰는 사람을 위한 내부 도구에는 완벽하지만, 보기 좋은 UI가 필요할 때는 어떡해야 할지 궁금함
    성능 면에서는 네이티브 UI가 항상 좋지만, 웹페이지보다 스타일링이 어렵다고 느껴왔음. Python GUI에서 Flutter나 SwiftUI처럼 큰 노력 없이 세련돼 보이는 스타일드 컴포넌트 묶음에 해당하는 것이 무엇인지 궁금함
    [0] https://raw.githubusercontent.com/PySimpleGUI/PySimpleGUI/ma...

    • 잘하느냐 못하느냐의 문제이긴 하겠지만, 내 경험상 “스타일드” UI는 많은 소프트웨어와 사용자에게 소프트웨어가 나빠지는 이유 중 하나였음
      최소한 운영체제가 제공하는 기본 UI 스타일은 사람들이 한 앱에서 배워 다른 앱으로 옮겨갈 수 있음. 내가 뛰어난 UI 디자이너가 아니니, 운영체제 기본값이 내가 떠올릴 수 있는 것보다 나을 가능성이 큼. 여기에 마케팅에서 듣기 두려운 “우리 소프트웨어가 오래돼 보인다”는 말까지 더해지면 개발 비용이 이미 버거운 수준으로 늘어남
    • 90년대 느낌 자체는 괜찮지만, 이건 90년대 운영체제 룩과도 맞지 않음. 체크박스 배경이 틀렸고, 위쪽 제목 라벨은 어긋나 있으며, Exit 버튼 위치도 이상해서 전체적으로 설계가 나쁜 UI처럼 보임
      90년대에도 이런 소프트웨어는 있었지만, 사람들이 흔히 말하는 90년대 미학은 아님. Windows 95 UI 디자인에는 많은 공이 들어갔음
    • 90년대 룩이 뭐가 문제인지 모르겠음. 좋아하는 사람도 많음
      요즘 UI의 넓은 여백, 버튼처럼 안 보이는 버튼, 사라지는 스크롤바, 햄버거 메뉴가 더 싫음
    • 외형이 최우선이라면 웹페이지를 이기기 꽤 어려워 보임
      프런트엔드와 백엔드 분리도 기본으로 되고, 나중에 필요하면 원격 접근도 가능함. 네이티브 앱처럼 쓰고 싶으면 작은 Tkinter류 GUI에 “Open browser UI” 버튼 하나만 넣어도 됨. 실행 버튼이 URL에 토큰을 넣게 하면 같은 머신의 다른 사용자로 실행 중인 데몬으로부터도 보호할 수 있는데, 실제로 이렇게 하는 곳은 못 봤음
    • 문제는 Tkinter가 적어도 Windows에서는 정말 90년대 위젯 기반이라는 데 있음. PySimpleGUI 테마를 SystemDefaultForReal로 바꿔도, 네이티브 Windows 위젯은 현대적인 외형인데 Tkinter는 전혀 업데이트되지 않아서 어색하게 보임

  • 괜찮아 보임. 다만 이 라이브러리가 이미 성숙해서 큰 변경이 어려울 수도 있지만, 리스트 대신 딕셔너리를 쓰면 좋겠음. 최근 Python의 딕셔너리는 삽입 순서를 기억함
    예전 직장에서 PyQt 위에 훨씬 얇은 래퍼로 비슷한 걸 만들었고, 코드도 놀랄 만큼 적었음. 핵심 차이는 속성/시그널 설정과 위젯 중첩을 함께 처리했다는 점임. 생성자에서 속성을 설정하는 방식보다, 나중에 텍스트를 바꾸기 위해 위젯 이름이 필요해도 뷰 정의의 본문에서 속성을 설정할 수 있다는 장점이 있었음. setup_view 함수 하나가 전체 API였고, 간단한 GUI를 빠르게 만들 때 꽤 편리했음. 이 라이브러리도 좋은 대안처럼 보여서 공유에 감사함

    • 그 변경은 Python 3.7에서 들어갔고, 이제 5년도 더 된 기능임
      https://docs.python.org/3/whatsnew/3.7.html#summary-release-...
    • 최근 GUI 프레임워크 흐름을 보면 레이아웃과 데이터 분리가 훨씬 깔끔한 코드를 만듦
      데이터 바인딩은 프레임워크가 맡게 두는 편이 좋음. 웹과 데스크톱 모두 점점 이 방향으로 가고 있음. 위젯을 직접 변경하기보다, 위젯 속성을 데이터 저장소에 바인딩하고 변경 시 자동 재렌더링되게 해야 함. 페이지의 입력/출력 예제가 비슷한 걸 보여줌. 이제 아무도 getElementById()를 쓰지 않음
    • GitHub 페이지에 따르면 “초보자가 이해하는 Python 핵심 데이터 타입인 리스트와 딕셔너리를 사용해 창 정의를 단순화했다”고 되어 있음

  • VB6나 Delphi/Lazarus의 사용 편의성에 가까워지는 것 같음. 확실히 발전은 있고, 이제 대화형 GUI 빌더만 있으면 만든 폼을 #import해서 바로 쓰는 식으로 끝날 수 있음
    몇 년 전 WxPython과 WxFormBuilder를 같이 쓰려다 프로젝트에서 엄청난 시간을 날렸음. 폼에서 작은 변경만 해도 백엔드가 전부 깨졌고, 중간 연결용 얇은 코드를 직접 썼지만 필드 타입을 바꾸자 또 전부 깨졌음. 여기서는 그런 일이 없을 것 같아 다행임

  • Python GUI 애플리케이션 [1]을 개발하는 입장에서, 데스크톱 앱에 Python을 쓸 때 가장 큰 문제는 패키징이라고 봄
    배포 가능한 바이너리를 만드는 기존 도구들은 의존성이 몇 개만 넘어가도 작동을 멈추거나 만만치 않은 해킹이 필요해짐. 인기 패키지조차 숨은 import 누락이나 몰랐던 데이터 파일 누락 같은 난해한 문제가 생김. 동적 모듈 로딩도 PyInstaller나 cx_freeze처럼 일반 Python 환경 밖으로 가져오면 깨질 때가 있음. 뭘 할 수 있을지는 모르겠지만, Python도 Java의 JAR처럼 인터프리터에만 의존하는 독립 실행 프로그램 패키징 표준이 필요할지도 모름

    1. https://github.com/FreeLanguageTools/vocabsieve
    • Python에는 표준화되어 있고 JAR와 비슷한 zipapp이 있음: https://peps.python.org/pep-0441/
      shiv나 PEX 같은 도구로 애플리케이션 의존성을 포함한 zipapp을 만들 수 있지만, 바이너리 확장이 있으면 산출물은 여전히 플랫폼별임: https://github.com/linkedin/shiv#gotchas
      내 Python 프로그램은 사용자에게 pipx로 설치하라고 권함: https://github.com/pypa/pipx
      대상 사용자가 조금이라도 기술적이라면 가장 좋은 선택이라고 봄. pip install --user의 버전 충돌과 앱별 가상환경을 수동으로 만드는 고통을 피하게 해주고, 전반적으로 괜찮은 사용자 경험을 제공함. pipx를 기본 설치 방법으로 권해도 사람들이 설치에 성공할 것이라 기대할 수 있음. 내 프로그램은 바이너리 의존성은 있지만 GUI는 없음

  • 개인적으로는 CustomTKinter가 더 마음에 듦. 훨씬 우아하고 Material 테마 같은 외형이며, Windows/Linux/macOS에서 시스템 설정에 따른 라이트/다크 테마를 지원함

  • 빠른 애플리케이션 개발 영역에서 VB6가 남긴 빈자리를 아직도 아무것도 제대로 채우지 못했다는 게 놀라움. 언어 자체는 훌륭하지 않았지만, VB6의 강점은 드래그 앤 드롭 GUI 빌더였음

  • 꽤 잘 만들어진 CLI 인터페이스가 있는 도구에 GUI를 씌워, 데스크톱 Linux를 쓰지 않는 사람도 사용할 수 있게 할까 고민 중임. PySimpleGUI가 내 필요에 딱 맞을 수도 있어 보임
    https://github.com/hiAndrewQuinn/finstem
    내 도구는 CSV, TSV, JSON 플래그가 잘 정의돼 있음. 기존의 완전한 CLI 도구를 바꾸지 않고 그 위에 GUI를 만든 경험이 있는지, 어떤 어려움을 예상해야 하는지 궁금함

    • 체스 엔진이 좋은 참고 사례임. 의사결정 부분은 CLI이고, WinBoard[0]나 Arena[1] 같은 GUI에 붙음
      엔진과 GUI는 WinBoard나 UCI[2] 같은 프로토콜을 따르며, STDIN/STDOUT으로 텍스트 명령을 주고받음. 주요 난점은 멀티스레딩에서 겪는 것과 같아서, GUI와 CLI가 서로를 기다리며 멈추는 교착 상태가 생길 수 있음. 그래서 양쪽 모두 입출력을 “비즈니스 로직”과 별도 스레드에서 처리해 반응성을 유지해야 함. 또 다른 흔한 문제는 파이프 처리에서 운영체제별 특성이 다르다는 점으로, 버퍼 flush나 Linux/Mac/Windows 간 API 차이를 신경 써야 함
      [0] http://hgm.nubati.net/
      [1] http://www.playwitharena.de/
      [2] https://gist.github.com/DOBRO/2592c6dad754ba67e6dcaec8c90165...
    • 예를 들면 HandBrake를 보면 됨. ffmpeg를 위한 화려한 UI에 가깝음

  • 무례하게 들리지 않았으면 하는데, 텍스트가 너무 많음. 텍스트를 넣을 수 있는 곳마다 긴 문장이 이어지고, 대부분 일관성은 있지만 첫 천 단어 동안 관련 스크린샷 하나도 없음
    뭔가 어긋나 보임. 아마 젊고 열정적인 개발자이거나, 사용해보도록 설득하려고 텍스트를 많이 넣은 것처럼 느껴짐. README에는 작성자가 자신을 소개하는 “about me” 섹션까지 있음. README의 아무 지점이나 내려가 몇 문단을 읽은 뒤 방금 읽은 내용을 다시 말해보면 예가 될 것임

    • 각 섹션에는 명확한 제목이 있음. 관심 없는 섹션이면 조금만 스크롤하면 됨. 아무도 “about me” 섹션을 읽으라고 강요하지 않음
      어떤 사람들은 “최소한의 단어만 읽고 최대한 빨리 실행하려면 어떻게 하지”라는 태도보다, 도구에 대해 읽는 것 자체를 즐김. 다른 사람이 만든 도구를 무료로 쓰는 것이니 불평을 멈추고 원하는 방식으로 표현하게 두는 게 좋음
    • “젊고 열정적인 개발자”라는 추측은 틀림. “About Me” [1]에는 70년대부터 소프트웨어를 작성했고, 경력 대부분을 Silicon Valley에서 제품을 만드는 데 보냈다고 되어 있음
      [1] https://github.com/PySimpleGUI/PySimpleGUI#about-me-
    • 그냥 훑어봤음. 투자자를 끌어들이려는 제품용 MVP가 아니라, 만든 사람이 직접 문서를 쓴 도구임
      무례하지 않기를 바라지만, 혹시 단계별 요약으로 떠먹여지지 않으면 글을 읽어야 한다는 사실 자체를 두려워하는 건 아닌지 되묻고 싶음
    • 꽤 무례한 표현이라고 봄. 특히 텍스트가 많은 이유를 둘 중 하나로만 줄였고, 둘 다 그다지 좋게 들리지 않음. 게다가 그 이유들이 맞는 것 같지도 않음
      같은 생각은 “시각적인 프로젝트라면 메인 설명에 스크린샷이 더 많아야 한다고 느낀다” 정도로도 전달할 수 있었고, 모욕적인 추측은 빼도 됐음
    • 프로젝트 이름을 Simple이라고 지은 게 문제일 수 있음. 독자 머릿속에 기대하는 선입견을 심어버리기 때문임
      Smart, Open, Trusted, Secure 같은 단어를 프로젝트 이름에 넣으면 사람들이 그 이름의 이상에 못 미친다고 짚어내기 쉬움. 반대로 C나 BSD 같은 이름은 반대말이나 함의가 없어서 “C 언어가 이름값을 못 한다”고 말하기 어려움
답변달기