문제

Haskell, wxwidgets를 사용하여 GUI 애플리케이션을 개발하는 데 더 좋습니다. Wxhaskell) 또는 gtk (비아 GTK2HS)?

각각의 장단점은 무엇입니까? 타겟팅하는 플랫폼에 따라 다릅니다 (주로 OS X에서 작업하고 있지만 내 프로그램이 Linux 및 Windows에서도 작동하기를 원합니까)?

도움이 되었습니까?

해결책

면책 조항 : 저는 WXHASKELL 관리자입니다

둘 다 안정적이고 상당히 완전한 GUI 바인딩이며, 대부분의 프로젝트에서 자신감을 가지고 선택할 수 있습니다. 둘 다 어느 정도의 '상위 수준'하스켈 바인딩이 있지만 두 경우 모두 일을 끝내려면 다소 명령적인 'C'스타일 코딩에 빠져야합니다. 저의 인상은 WXHASKELL이 높은 수준의 바인딩에서 시간을 조금 더 보낼 수 있다는 것입니다. 그러나 나는 많은 GTK2HS를 수행하지 않았으며, 어쨌든 두 라이브러리의 래퍼의 얇은 끝에서 일하는 것을 확실히 발견합니다. 그리고 전반적인 프로그래밍 '복잡성'은 두 경우 모두 비슷하다고 생각합니다.

따라서 기본 기능을 주어진 것으로 받아들이고 차이점에 집중합시다. GTK2HS는 훌륭한 작품이며 선택하면 행복 할 것입니다. 내가 아래에서 말하는 대부분의 것은 차이점에 대한 개인적인 취향과 Wxhaskell과 함께 일하기로 선택한 이유입니다.

GTK2HS는 더 큰 팀을 구성하고 있으며보다 정기적으로 출시됩니다. WXHASKELL은 자주 업데이트되지 않지만 핵심 팀은 활성화되어 있으며 일반적인 버그 문제가 있지만, 새로운 기능이 우리가 원하는 것보다 더 느리게 추가됩니다 (우리 모두는 일자리가 있습니다).

WXHASKELL은 모든 지원되는 플랫폼에서 진정한 기본 응용 프로그램 모양을 제공합니다. GTK2HS는 물론 Linux에서 기본이며 Windows에서 매우 좋은 기본 테마를 가지고 있지만 (예 : 모든 페넌트를 제외한 모든 것을 만족시키기에 충분합니다 ...) OSX에 GTK 모양과 느낌이 있으며 X11을 설치하는 데 달려 있습니다. 나는 OSX 'Native'GTK 라이브러리가 개발 중이지만 상대적으로 미숙 한 것으로 간주된다고 생각합니다. 이것이 안정되면 GTK2HS GTK OSX 스크린 샷).

WXHASKELL은 Linux에 있지 않으면 구축하기가 조금 더 쉽습니다 (Linux가 호스팅 된 경우 GTK2HS는 더 쉽습니다). 그러나 두 경우 모두 상당한 의존성이 있기 때문에 정직하게 구축하기가 매우 복잡합니다.

라이브러리 의존성이 적기 때문에 WXHASKELL을 기반으로 응용 프로그램을 배포하는 것이 약간 쉽습니다 (IMHO). Windows에서 주로 innosetup과 OSX의 앱 번들로 응용 프로그램을 배포합니다. 나는 소량의 추가 작업만으로도 GTK2HS에서도 동일하게 수행 할 수 있음을 인정할 것입니다. 그래서 이것은 아마도 WXHASKELL에 유리한 가장 약한 주장 일 것입니다.

Wxhaskell이 폐쇄 소스 (예 : 상업) 개발에 더 친숙하다는 것은 개인적인 의견입니다. 물론 이것은 얽힌 불꽃 전쟁의 주제이므로 wxhaskell이 아래에 있다고 말할 것입니다. wxwidgets 라이센스 닫힌 소스 개발이 확실하게 허용됩니다. GTK2HS는 LGPL이므로 변호사에게 물어봐야합니다. 많은 사람들과 회사가 LGPL이 상업적 개발과 호환되었다는 결론을 내렸다는 것을 분명히해야합니다. 내가 일하는 회사의 변호사들은 우리 프로젝트에 부적절하다고 결론을 내 렸습니다.

Linux가 저의 주요 개발 및 전달 플랫폼이라면 아마도 GTK2HS를 사용할 것입니다. 그러나 나는 가끔 OSX를 가진 Windows에 주로 전달하며 WXHaskell 이이 플랫폼과 더 잘 어울린다고 생각하지만 두 옵션 모두 세 가지 플랫폼을 모두 지원합니다.

이것이 당신의 선택에 도움이되기를 바랍니다.

다른 팁

고려 사항은 현재 WXHASKELL이 Mac OS X에서 기본적으로 작동하는 것이 약간 쉽다는 점입니다. GTK2HS는 Mac OS X에서 기본 위젯을 사용하는 구현이있는 GTK에 따라 다르지만 WXWIDGETS 구현만큼 쉽게 구축되지는 않습니다. Mac OS X의 경우.

따라서 X11.App없이 실행할 코드를 개발하려면 현재 WXHASKELL을 약간 더 잘 수행합니다.

그러나 이것은 빠르게 변화하고 있습니다.http://www.haskell.org/haskellwiki/gtk2hs#using_the_gtk.2b_os_x_frameworkMac OS X에서 GTK+와 함께 GTK2HS를 사용하는 방법을 보여줍니다.

GTK2HS의 장점 중 하나는 Glade 지원으로 간단한 UI의 개발을 매우 빠르게 만듭니다. WXHASKELL의 높은 수준의 콤비네이터는 이러한 이점의 대부분을 완화하지만 인터페이스가 어떻게 보이고 행동하기를 원하는지에 대한 더 깊은 이해가 필요하므로 탐색 적 방식으로 사용하기가 더 어렵습니다.

나는 매우 불완전한 정보를 가지고 있지만 아직 답이 없기 때문에 불완전한 정보가 없을 것입니다.

묻는 질문은 이것입니다. 툴킷은 C와 같은 기능을 중심으로 래퍼 일뿐입니다. 아니면 툴킷에 더 "기본 Haskell과 같은"API를 제공하는 추가 레이어가 있습니까? Wxhaskell이 Haskell Workshop에서 처음 발표되었을 때, 원주민 Haskell API의 개발은 매우 유망한 것처럼 보였지만 여전히 불완전했습니다. Wxhaskell의 "Haskellized"API가 여전히 작업중인 것처럼 보이지만 GTK2HS 프로젝트는이 문제를 전혀 언급하지 않습니다. 이런 이유로 나는 wxhaskell을 추천합니다.

개인적으로 나는 일종의 반응성 패키지/확장을 조사 할 것입니다. 그것은 패러다임과 훨씬 더 가깝게 앉아있는 것 같습니다. 그래픽 내용을 필수적으로 지정하는 대신 선언적으로 수행 할 수 있습니다. 예 (특정 언어 또는 구현을 대표하지 않음) :

x, y, z              :: Int
click, buttonclicked :: Bool
x = <X coordinate of mouse>
y = <Y coordinate of mouse>
click = <Whether mouse button is currently being pressed>
z = x + y
buttonclicked = (x == 10 && y == 10 && click)

ButtonClicked 및 Z는 X 및 Y가 변경 될 때마다 자동으로 업데이트됩니다.

그런 다음 다음과 같이 보이는 어딘가에 논리를 가질 수 있습니다.

if buttonclicked then <do something> else <do something else>

그래도 이것은 모두 매우 퍼지입니다. 실제 반응성 인터페이스를 살펴보십시오

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top