너무 많이 쓰여서 다소 혼란스럽습니다. 하지만 제가 착각하지 않는다면 Canonical은 Qt를 사용하여 모바일 장치용 차세대 Unity를 구축하고 있으며 가까운 시일 내에 데스크톱도 Qt로 마이그레이션할 예정입니다.
저는 이 결정을 내리는 기술적 및/또는 정치적 이유와 이것이 현재 기존 Ubuntu 데스크톱 응용 프로그램에 어떤 영향을 미칠 수 있는지 알고 싶었습니다.
답변1
메일링 리스트와 다음에서 답변을 찾을 수 있습니다.마크 셔틀워스의 블로그. 이 블로그 게시물이 아마도 가장 잘 대답할 것입니다.
Natty+1 계획의 일환으로 CD에서 Qt 라이브러리용 공간을 찾아야 하며, CD에 포함될 수 있도록 Qt로 개발된 애플리케이션과 Ubuntu 기본 설치를 평가할 것입니다.
사용 편의성과 효과적인 통합은 사용자 경험의 핵심 가치입니다. 우리는 우리가 선택하는 애플리케이션이 서로, 그리고 시스템 전체와 조화를 이루는지 중요하게 생각합니다. 역사적으로 이는 우리가 Gtk를 사용하여 작성된 애플리케이션을 매우 선호한다는 것을 의미합니다. 동일한 개발자 툴킷을 사용하면 기본적으로 어느 정도 조화가 이루어지기 때문입니다. 즉, OpenOffice와 Firefox가 처음부터 존재했기 때문에 Gtk는 분명히 절대적인 요구 사항은 아닙니다. 지금 내가 주장하는 것은 중요한 것은 가치이고 툴킷은 그 목적을 위한 수단일 뿐이라는 것입니다. 우리는 개발자가 선택한 기술적 선택을 기준으로 앱을 편견하는 것이 아니라 요구 사항을 얼마나 잘 충족하는지 기준으로 앱을 평가해야 합니다.
Ubuntu 기본 설치용 앱을 평가할 때 다음 사항을 질문해야 합니다.
- 자유 소프트웨어인가요?
- 동급 최고야?
- 시스템 설정 및 기본 설정과 통합됩니까?
- 다른 애플리케이션과 통합되나요?
- 마우스나 키보드를 사용할 수 없는 사람도 접근할 수 있나요?
- 시스템의 나머지 부분과 모양과 느낌이 일치합니까?
물론 개발자의 Qt 선택은 처음 두 가지에 영향을 미치지 않습니다. Qt 자체는 오랫동안 GPL 하에서 사용 가능했으며 최근에는 LGPL 하에서 사용 가능해졌습니다. 그리고 Qt로 작성된 동급 최고의 소프트웨어가 많이 있으며 매우 유능한 툴킷입니다.
그러나 시스템 설정과 기본 설정은 오랫동안 Qt와 Gtk 사이의 마찰의 원인이었습니다. 시스템 설정 및 기본 설정과의 통합은 응용 프로그램이 시스템에 "속해있다"는 느낌을 주는 데 매우 중요합니다. 이는 다른 모든 애플리케이션을 관리하는 데 사용하는 것과 동일한 도구를 사용하여 해당 애플리케이션을 관리하는 능력과 사용자가 앱에서 가질 수 있는 일종의 설정 및 기본 설정 경험에 영향을 미칩니다. 이것은 전통적으로 Ubuntu의 Qt/KDE 응용 프로그램에서 문제가 되어 왔습니다. Gtk 응용 프로그램은 모두 중앙에서 관리 가능한 기본 설정 저장소를 사용하고 KDE 응용 프로그램은 다르게 작동하기 때문입니다.
이 문제를 해결하기 위해 Canonical은 Qt용 dconf 바인딩 개발을 추진하고 있으므로 Ubuntu의 다른 모든 것과 동일한 설정 프레임워크를 사용하는 Qt 앱을 작성할 수 있습니다. 우리는 dconf를 아주 잘 알고 있는 Ryan Lortie와 계약을 맺었고 그는 고객을 위한 맞춤형 개발 작업을 위해 Qt를 사용해 온 Canonical의 일부 사람들과 함께 일할 것입니다. 우리는 결과가 Qt 개발자에게 자연스럽고 dconf의 의미와 스타일이 완벽하게 표현될 것이라고 확신합니다.
Qt 팀은 광범위한 Ubuntu 커뮤니티에서 오랫동안 잘 일해 왔습니다. 우리는 6개월마다 UDS에서 훌륭한 Qt 대표자를 보유하고 있으며 Kubuntu 팀은 Qt 패키징 및 유지 관리에 대한 깊은 경험과 관심을 가지고 있으며 Qt 업스트림과 다양한 팀 간에 좋은 기술 교환이 많이 있습니다. Canonical을 포함한 Ubuntu 커뮤니티의 일부. 예를 들어, Qt 사람들은 uTouch를 통합하기 위해 노력하고 있습니다.
나는 "Qt"와 "KDE"를 분명한 부분에서 구별하고 싶습니다. KDE 앱은 dconf 시스템 구성에 대해 아무것도 모르므로 결과적으로 Ubuntu 데스크탑과 쉽게 통합할 수 없습니다. 따라서 우리는 곧 Banshee를 대체하기 위해 Amarok을 제안하지 않을 것입니다! 그러나 나는 훌륭한 Qt 바인딩을 갖춘 dconf가 KDE 커뮤니티에서 고려되는 것이 전적으로 타당하다고 생각합니다. 원하는 경우 대화를 이끌어갈 더 나은 사람들이 있으므로 여기서는 그 아이디어를 더 이상 추진하지 않겠습니다. 그럼에도 불구하고, KDE 앱이 표준 KDE 메커니즘 외에 dconf를 사용하는 방법을 배우면(간단해야 함) Ubuntu 기본 설치의 후보가 될 것입니다.
Qt를 공개하기로 한 결정은 결코 GNOME에 대한 비판이 아닙니다. 이는 자유 소프트웨어의 다양성과 복잡성을 기념하는 것입니다. 사용 용이성과 통합이라는 가치는 GNOME과 공유되는 가치로 남아 있으며 GNOME 개발자 및 프로젝트 구성원과의 협력을 위한 훌륭한 기반입니다. 아마도 GNOME 자체가 Qt를 수용할 수도 있고 아닐 수도 있지만, 만약 그렇다면 이 길을 개척하려는 우리의 의지는 리더십에 기여할 것입니다. 정식 방식에서 어느 정도의 차이를 수용한다면 활기찬 생태계를 만드는 것이 훨씬 쉽습니다. 말하자면 우리의 디자인 작업은 GNOME을 중심으로 이루어지며, GNOME 3.0 및 gtk3으로 전환함에 따라 설정 및 기본 설정에 현재 초점이 맞춰져 있습니다.
물론 이것은 그 관계를 비웃는 사람들에게 완벽한 기회이지만, 내 생각에 가장 중요한 것은 실제로 그놈이라는 깃발 아래 응용 프로그램을 작성하는 사람들과 우리가 갖고 있는 탄탄한 관계입니다. 우리는 자유 소프트웨어 개발자들의 노고를 돋보이게 하는 최선의 방법이 되고 싶습니다.문제, 이는 매일 수백만 명의 삶에 실질적인 변화를 가져오는 최선의 방법이자 이를 사용자와 연결하는 최선의 방법을 의미합니다.
Qt를 훌륭한 툴킷으로 만들어준 Trolltech(현 Nokia)의 좋은 사람들에게 감사드립니다. 이를 사용하고 Ubuntu 경험의 일부가 되기를 원하는 개발자 여러분을 환영합니다.
답변2
GTK+는 해상도 독립성을 지원하지 않습니다. 최신 모바일 장치는 매우 높은 픽셀 밀도를 가지고 있습니다. 모바일 화면에서 GTK+ 애플리케이션을 실행하면 모든 사용자 인터페이스 요소가 너무 작아서 사용할 수 없게 됩니다.
이것은GTK+의 공개 버그2008년부터 2014년에 "우리는 이제 hi-dpi 스케일을 지원합니다. 완전히 똑같지는 않지만 이 버그를 더 이상 사용하지 않게 만들 만큼 가깝습니다"라는 코멘트와 함께 종료되었습니다.
GTK+3이 출시되었을 때 프로젝트는 해상도 독립성을 추가할 수 있는 완벽한 기회를 가졌습니다. 어쨌든 호환성이 깨졌기 때문입니다. 그들은 그렇게 하지 않기로 결정했고 이제는 정말 너무 늦었습니다.
에GTK+ 로드맵, 해상도 독립성은 4.0 이후 릴리스에 계획되어 있으므로 4.0을 릴리스한 다음 그 이후의 주요 릴리스에서 이를 갖게 됩니다. 그들이 그 계획을 고수한다면 데스크탑 GNU/Linux조차도 GTK+를 포기해야 할 것입니다. 높은 DPI 데스크탑 모니터와 노트북 모니터가 이미 사용 가능하고 곧 새로운 표준이 될 것이기 때문입니다.
답변3
우분투 CTO매트 짐머만의 블로그또한 유익합니다:
제가 최근 Qt에 대해 생각한 것은 바로 이러한 정신입니다. 우리는 Ubuntu용 애플리케이션을 빠르고 쉽고 간편하게 개발할 수 있기를 원하며, Qt는 애플리케이션 개발자가 살펴볼 가치가 있는 옵션입니다. 이에 대해 생각하면서 Qt의 강점과 Ubuntu의 새로운 방향 사이에 상당한 공통점이 있다는 것을 깨달았습니다.
- Qt는 오랫동안 사용되어 왔습니다.ARM뿐만 아니라 x86, 임베디드 장치에서 인기가 있기 때문입니다. 소비자 제품은 10년 넘게 ARM 기반 Qt를 사용하여 제작되었습니다. 우리는 거의 2년 동안 ARM용 Ubuntu 제품을 제공해 왔으며 10.10은 Freescale, Marvell 및 TI의 레퍼런스 보드를 포함하여 이전보다 더 많은 ARM 보드를 지원합니다. Qt는 최신 ARM 칩에 이점을 제공하기 위해 ARMv7 최적화를 추가하고 있습니다. 우리는 소프트웨어 선택권을 희생하지 않고도 OEM에게 하드웨어 선택권을 제공하기 위해 이렇게 합니다. Qt는 애플리케이션 개발자를 위해 이와 동일한 선택을 유지합니다.
- Qt는크로스 플랫폼Windows, MacOS 등을 위한 공식 포트와 Android, iPhone 및 WebOS에 대한 실험적인 커뮤니티 포트를 갖춘 애플리케이션 프레임워크입니다. 강력한 크로스 플랫폼 지원은 Qt의 원래 원칙 중 하나였으며 이는 공식 포트의 성숙도에서 드러납니다. Windows가 설치된 컴퓨터에 Ubuntu Light가 설치되고 Android 및 iPhone에 Ubuntu One이 설치되므로 다른 플랫폼과의 상호 운용성이 필요합니다. Windows를 대상으로 하는 방법을 이미 알고 있고 Qt를 선택하여 Ubuntu 사용자에게도 접근할 수 있는 개발자 집단도 많습니다.
- Qt는 상당히 성숙한터치 입력이 시스템은 이제 멀티 터치 및 제스처(QML 포함)를 지원하지만 Windows 7 및 Mac OS X 10.6에서만 완성됩니다. 한편 Canonical은 커뮤니티와 협력하여 Qt 및 기타 툴킷의 이점을 위해 Linux 및 X11용 하위 수준 멀티 터치 프레임워크를 개발해 왔습니다. 이러한 노력은 결국 중간에서 만나게 될 것입니다.
전반적으로 Qt는 특히 현재 Ubuntu용 애플리케이션을 개발하려는 사람들에게 많은 것을 제공한다고 생각합니다. 전체 쿠분투 배포판은 말할 것도 없고 VLC와 같은 인기 있는 크로스 플랫폼 애플리케이션을 이미 지원하고 있습니다. 작년에 이런 일이 발생했을 때 놓쳤지만 이제 Qt는 LGPL 2.1 또는 GPL 3.0에서 사용할 수 있으므로 거의 모든 Ubuntu 응용 프로그램에 적합합니다. 강력한 상업적 지원과 대규모 개발자 커뮤니티를 보유하고 있습니다. 물론 단일 솔루션이 모든 개발자의 요구 사항을 충족할 수는 없으며 Ubuntu는 이러한 이유로 여러 툴킷과 프레임워크를 지원하지만 Qt는 앞으로 나아갈 도구 상자에 포함할 수 있는 훌륭한 도구인 것 같습니다.
안아르스 테크니카 기사이 블로그 게시물에 대해 논의하면 다음과 같은 통찰력을 얻을 수 있습니다.
Qt는 타사 개발자를 Linux로 가져올 수 있습니다
Gtk+는 여전히 가치가 있고 기본 Linux 소프트웨어를 구축하는 데 이를 계속 사용해야 할 여러 가지 이유가 있지만 이제 Qt는 여러 플랫폼을 대상으로 하는 ISV에게 확실한 선택입니다. Qt를 사용하면 기본 플랫폼의 기본 모양과 느낌을 매우 쉽게 따르거나 대상 장치 또는 폼 팩터에 가장 적합한 완전히 사용자 정의된 사용자 인터페이스를 구축할 수 있습니다.
Nokia와 Intel이 MeeGo를 다양한 장치에 도입함에 따라 일부 주요 상용 소프트웨어 공급업체의 관심을 끌게 될 것입니다. 해당 소프트웨어 회사가 MeeGo에서 사용하는 것과 동일한 코드를 사용하여 모바일 Qt 애플리케이션을 Linux 데스크톱으로 가져오는 것은 상대적으로 쉬울 것입니다. Qt는 이를 쉽게 할 수 있도록 특별히 설계되었습니다. 이는 다른 방법으로는 사용할 수 없는 타사 응용 프로그램을 가져올 수 있기 때문에 데스크탑 Linux에 큰 승리가 될 것입니다.
Nokia의 툴킷 지원으로 인해 일부 저명한 모바일 소프트웨어 공급업체가 이미 Qt를 적극적으로 수용하고 있다는 점은 주목할 가치가 있습니다. 예를 들어, 모바일 비디오 스트리밍 회사인 Qik은 자사의 인기 애플리케이션을 MeeGo에 적용할 목적으로 실험적인 Qt 기반 포트를 개발 중입니다.
이 기사의 저자는 Gwibber IM 앱의 제작자이므로 Linux용 GUI 개발 경험이 있습니다.
답변4
기술적/실용적 이유에 대한 나의 견해: Nokia는 Trolltech를 인수하고 QT에 많은 투자를 했습니다. 가볍고 모바일 플랫폼에 대한 수년간의 최적화가 이루어졌습니다. Nokia에 대한 귀하의 현재 의견에 관계없이 N900은 시대보다 몇 년 앞서 있었고 데비안/QT 기반이었지만... 가격이 비쌌습니다. 그러나 나는 결정에 대한 실제 지식이 없습니다.