Haskell의 GUI 라이브러리에 대한 제안 [닫기]

Haskell Wiki 자체는 다음과 같이 말합니다 .

하스켈에는 많은 GUI 라이브러리가 있습니다. 불행히도 표준적인 것이 없으며 모두 불완전합니다. 일반적으로 저수준 베니어는 잘 진행되고 있지만 저수준입니다. 높은 수준의 추상화는 매우 실험적입니다. 지원되는 중간 레벨 GUI 라이브러리가 필요합니다.

저의 대학 교수가 저와 다른 3 개의 컴퓨터 과학 전공에게 Haskell의 GUI 라이브러리 작업을 고려해 보라고 요청했습니다. 프로젝트에 대한 그의 초기 아이디어 는 스몰 토크에서 발견되는 모픽 라이브러리 를 모방 한 OpenGL 위에 레이어를 작성하는 것이 었습니다 . 그러나 이것은 제안 일 뿐이며 다른 시스템은 반드시 고려할 가치가 있습니다.

이것은 우리에게 실제적인 여러 부분으로 이루어진 질문으로 이어집니다.

1. 도서관은 어느 수준의 추상화를 위해 노력해야합니까? Haskell Wiki는 중간 수준의 GUI 라이브러리가 선호 될 것임을 강력하게 나타내는 것 같습니다. 그러나 높은 수준의 라이브러리는 여전히 환영받을 것입니다.
2. 우리 도서관은 무엇을 건축해야합니까? (예 : OpenGL)
3. 기존의 어떤 GUI 라이브러리를보고 싶습니까? (예 : PyGame, Morphic, Swing 등)
4. 우리 도서관이 어떤 기능을 구현하거나 피하고 싶습니까? 예를 들어 그놈의 훌륭한 사람들은 최소화 버튼이 필요하지 않다고 주장 할 수 있습니다.
5. 일반적인 제안 사항이 있습니까?
6. 이 가상의 도서관에 어떤 영리한 이름을 하시겠습니까? (예 : HOT-Haskell Opengl Toolkit; HAWT-Haskell Advanced Windowing Toolkit)

Haskell과 함께 사용하기에 우아하고 간단한 라이브러리를보고 싶습니다. 나머지는 재정의하지 않고이 목적에 부합해야하는 기술적 세부 사항입니다. 따라서 내 $ 0.02.

Qt, GTK 또는 FLTK와 같은 기존 툴킷을 기반으로하지 마십시오. 이렇게하면 심각하게 제한되어 이익보다 훨씬 많은 고통을 줄 수 있습니다. PyQt는 erm, 재미 있고 충분히 고안되었으며 Python과 C ++ 모두 매우 유연한 명령형 OO 언어입니다. Haskell의 경우 상황이 훨씬 더 거칠다고 생각합니다.

가장 기본적인 그래픽 프리미티브에만 의존 하고 그 위에 빌드하십시오. OpenGL은 훌륭하지만 더 간단한 것 (예 : SDL) (예 : SDL)도 좋습니다. 이것은 최대의 유연성 과 최대의 이식성을 제공합니다. Smalltalk / Morphic, Java / Swing, TCL / Tk를 참조하십시오.

개념적으로 작게 만드십시오. GUI는 그대로 사용하기 때문에 다른 에베레스트를 추가 할 필요가 없습니다. Haskell은 소형화 및 모듈화를 지원할 수 있기를 바랍니다.

보너스 포인트의 경우 스킨을 만들 수 있습니다. 최소한이 툴킷으로 빌드 된 앱이 눈에 띄지 않도록 시스템 색상 (및 시스템 색상 만)을 적용하여 전체 컨트롤 레퍼토리를 페인트하는 방법을 알아야합니다. 최대한, Win32 / Gtk / Qt / Cocoa가 컨트롤을 완전히 네이티브하게 보이도록 만드는 방법을 숙지하십시오. 기본 스킨 기능은 간단하고 논리적입니다. 완전한 기본 모양을 얻는 것은 매우 어렵습니다.

또한 루트없이 실행하고 창 관리를 기본 그래픽 시스템 ( X, Windows 등)으로 남겨 두십시오 . 그렇게하지 않으면 사용자의 정신에 도전하고 채택을 방해 할 수 있습니다.

평소와 같이 '간단하고 복잡한 것을 가능하게하십시오'+ '모든 것이 가능하지만 관심있는 것은없는 튜링 타르타르를 피하십시오'+ '가능한 한 단순하지만 단순하지는 않습니다.'

이름이 가장 중요하지 않습니다. 모든 인기있는 GUI 툴킷 중에서 Qt만이 영리한 이름을 가지고 있습니다. 많은 인기있는 프로젝트가 기내에서도 (Firefox, née Firebird) 이름을 변경했습니다. 이름을 지정할 것이 있으면 이름을 지정할 수 있습니다.

행운을 빕니다!

관련된 모든 학생들과 이야기를 나누고이 질문에 흥미를 유발할 수있는 충분한 시간을 준 후에, 나는 원래 게시물의 몇 가지 주요 질문에 대해 합의에 도달했다고 생각합니다.

도서관은 어느 수준의 추상화를 위해 노력해야합니까? Haskell Wiki는 중간 수준의 GUI 라이브러리가 선호 될 것임을 강력하게 나타내는 것 같습니다. 그러나 높은 수준의 라이브러리는 여전히 환영받을 것입니다.

우리는 Haskell Wiki의 제안에 따라 중간 레벨 라이브러리를 목표로 결정했습니다.

우리 도서관은 무엇을 건축해야합니까? (예 : OpenGL)

우리는 인기와 지원으로 OpenGL을 선택했습니다. 우리는 중 하나를 사용하는 것 GLUT 또는 GLFW 의 거점으로 프로젝트 랩퍼 하스켈.

기존의 어떤 GUI 라이브러리를보고 싶습니까? (예 : PyGame, Morphic, Swing 등)

우리는 PyGame과의 상당한 토론 끝에 Morphic을 선택했습니다. 우리는 QT 나 GTK를 고려하지 않았다. 둘 다 이미 개발중인 Haskell 라이브러리 프로젝트 가 하나 이상 있기 때문 이다.

이 가상의 도서관에 어떤 영리한 이름을 하시겠습니까? (예 : HOT-Haskell Opengl Toolkit; HAWT-Haskell Advanced Windowing Toolkit)

이것은 여전히 ​​논쟁의 여지가 있습니다. 우리는 HAWT를 고려하지 않기로 결정했으며 대신 다음을보고 있습니다.

• 핫-Haskell Opengl 툴킷
• HOG-Haskell Opengl Graphics (프로젝트를 HOG로 만드십시오!)
• ö