Java 프로그램을 '기본 모양'으로 만드는 것이 어려운 이유는 무엇입니까?

대부분의 Java 응용 프로그램은 C / C ++ 응용 프로그램과 동일하게 보이지 않습니다. Swing은 의도적으로 눈에 띄지 않게 디자인되었지만, 내가 읽은 내용을 기반으로 SWT는 예를 들어 '기본 모양'을 시도했지만 완전히 성공하지 못했습니다.

내 질문은 :

Java 언어 개발자 가 기본 GUI의 모양을 정확하게 복사하는 GUI 시스템을 설계하기 어려운 이유는 무엇 입니까? 기본 GUI의 차이점은 무엇입니까? '네이티브'버튼처럼 보이는 버튼을 디자인하는 것이 문제가 아닌가? 아니면 그것보다 더 깊어 집니까?

'네이티브'버튼처럼 보이는 버튼을 디자인하는 것이 문제가 아닌가?

글쎄요, 일종의 버튼입니다. 그러나 이것은 당신이 상상하는 것보다 어려울 수 있습니다. 요즘 GUI 구성 요소를 나타내는 데 사용되는 그래픽은 확장되지 않은 임의의 비트 맵만큼 간단하지 않습니다.이 비트는 전혀 확장되지 않기 때문에 종종 코너 기반 사례가 많은 벡터 기반 그래픽입니다 ( 버튼이 화면 가장자리에 도달하면 예를 들어 약간 다르게 보일 수 있습니다.) 물론 버튼을 클릭하면 다른 그래픽이 필요합니다. 저작권상의 이유로 개발자는 이러한 기존 그래픽을 그대로 사용할 수없는 경우가 많으므로 다시 작성해야합니다. 대부분 좋은 작업을 수행하는 동안 불가피하게도 그래픽 구성 요소가 너무 많아 일부 항목을 놓치게됩니다.

물론 위의 모든 내용은 Swing을 기반으로합니다. 물론 경량의 기본이 아닌 GUI 툴킷입니다. SWT 가 네이티브 이기 때문에 SWT 가 네이티브 처럼 보이지 않습니다 . JNI를 사용하여 기본 구성 요소를 호출하는 툴킷이므로 무언가가 제대로 보이지 않으면 모양과 느낌으로 인한 것이 아닙니다.

일부 시스템에서는 문자 그대로“네이티브”로 간주 될 수있는 툴킷이 수십 개가 있습니다. 이들 중 일부는 고유 한 개념이나 기능을 가지고 있으며이를 크로스 플랫폼 툴킷으로 복제하는 것은 지루합니다. 응용 프로그램의 모양과 느낌은 "스킨"에 의해 결정될뿐만 아니라 레이아웃과 작동 방식에 따라 결정됩니다. 몇 가지 고려 사항 :

• 대화 상자에서“OK”버튼은 어느쪽에 있습니까? 왼쪽 또는 오른쪽? 충분합니다. 각 시스템마다 별도의 대화 상자를 만들어 봅시다.
• 화면에서 기본 버튼을 어떻게 표시합니까? 컬러 틴팅, 굵은 글꼴, 버튼 확대? 충분히, 스타일 시트에 넣자.
• Windows에서 "리본"개념은 다소 고유합니다. 리본이 일반적이지 않은 Mac으로 어떻게 변환됩니까? 충분하지만 픽셀 단위의 정확한 레이아웃을 잊어 버리고 각 시스템마다 다른 툴바 구현을 제공합니다.
• 메뉴 막대가 창의 일부입니까 (Windows, 선택적으로 KDE) 또는 화면 맨 위에 있습니까 (Mac, Unity)? 충분히 픽셀 단위의 레이아웃을 이미 버렸으므로 각 시스템마다 다른 구현을 작성해 봅시다.
• 글꼴은 어떻게 렌더링됩니까? 가능한 한 선명합니까, 매끄럽고 앤티 앨리어싱입니까? 어떤 글꼴을 사용해야합니까? 글꼴마다 다른 메트릭이 있으므로 동일한 너비로 렌더링 된 동일한 단락의 글꼴에 따라 줄 수가 다를 수 있습니다.
• 창의 배경이 단색, 이미지 또는 그라디언트입니까? 스타일 시트에도 넣겠습니다.
• 스크롤바는 어떻게 보입니까? 버튼이 있다면 어디에 있습니까? 포인터가 특정 영역으로 움직일 때 얼마나 넓습니까?
• 다른 색 구성표를 어떻게 통합합니까?
• 드래그 가능한 것은 무엇입니까? 상황에 맞는 메뉴는 어디에 있습니까?

이러한 문제는 응용 프로그램의 동작 또는 일반 레이아웃을 터치 할 때 간단한 스타일 시트를 통해 해결할 수 없습니다. 유일한 해결책은 각 시스템에 대해 응용 프로그램을 다시 작성하는 것입니다 (따라서 Java의 크로스 플랫폼 이점을 무시 함). 유일한 현실적인 솔루션은 픽셀 단위의 정확한 레이아웃을 잊고 시스템 별 툴킷을 통해 추상화되는 공통 인터페이스에 쓰는 것입니다. Swing이 취한 해결책은 다양한 시스템을 모방하는 것입니다.

그리고 모든 플랫폼에서 앱이 똑같이 보일 수 있다는 플랫폼 간 일관성이 있습니다. 데스크톱 응용 프로그램에서 이는 성가 시며 사용자의 기대를 무너 뜨립니다.

그렇습니다.

이 버튼 만 만들면 Windows 또는 OS X 버튼처럼 보이는 버튼을 쉽게 작성할 수 있습니다. 그러나 버튼은 원래 버튼과 같이 "동작"해야합니다. 쉽지 않을 수 있습니다. 사용 가능한 버전 하나에 더 많은 공간이 있지만 다른 버전에는 없을 수 있습니다. Windows 버전의 디자인에 색상이 더 적합 할 수도 있습니다.

전체 GUI가 있으면 OS X 프로그램의 내용이 Windows 프로그램과 다르게 표시됩니다. 이것은 하나의 GUI에서 캡처하는 것이 불가능한 것입니다. 두 개의 GUI가 필요하지만 많은 응용 프로그램이 그렇게 소란스럽지 않습니다. 대신에 그들은 "대부분의 시스템에서 괜찮아 보인다"는 것을 목표로하고있다. 이것은 여전히 ​​다소 외계인이지만, 사용하기 쉽고 개발하기가 훨씬 쉽다.

OSX 버튼, Windows 버튼 또는 다른 툴킷과 같은 버튼을 만드는 것은 어렵지 않습니다. 그러나 대부분의 환경에 대한 UI 지침은 "이것은 버튼 모양"의 기본만큼 간단하지 않습니다. UI 요소 사이의 간격에서 메뉴 시스템의 기본 설정 / 옵션 대화 상자의 정확한 위치까지 목록에서 잘 알려진 특정 동작이 나타나는 순서에 이르기까지 미묘한 차이가 있습니다. 매우 간단한 사용자 인터페이스를 위해 가장 일반적인 경우를 자동화 할 수 있지만 대부분의 UI 작업은 훨씬 미세한 터치가 필요합니다.

SWT는 이것을 어느 정도 자동화하려고 시도했지만 다시 한번 간단한 UI 작업에 적합합니다. 그러나 모든 규모에 맞는 솔루션은 없으므로 UI가 복잡해지면 사용하는 기본 방법이 무너지기 시작합니다. 일반적으로 번거로운 수동 UI 작업으로 다시 가져올 수 있지만 대부분의 프로그래머가 모든 플랫폼에서 할 수 있거나 기꺼이 할 수있는 것은 아닙니다.

이에 대한 Swing의 접근 방식은 가능한 경우 기본 툴킷을 간단히 피하는 것이 었습니다. 네이티브가 아니며 시도하지 않습니다. 대신, 실행되는 위치에 관계없이 (거의) 똑같이 보이는 무언가를 만들려고 시도합니다. 모든 사람을 기쁘시게하려고 노력하기보다는 스스로를 기쁘시게하려고 노력했지만 그것이 성공하는 한 그 결과가 더 광범위한 사용자 커뮤니티에 얼마나 효과적인지 의문을 가질 수 있습니다.

응용 프로그램이 모든 시스템에서 가능한 한 자연스럽게 보일 것을 기대하고 각 시스템에서 응용 프로그램이 동일한 방식으로 작동 할 것을 기대하는 것 사이에는 상충 관계가 있습니다. "올바른"선택은 없습니다.

또한 "자연스럽게 보이는"면을 선택하더라도 기본 툴킷 및 API의 "개선"으로부터 그래픽 툴킷 사용자를 보호하여 응용 프로그램이 예기치 않게 중단 될 수 있습니다.

그렇기 때문에 일부 GUI 툴킷 개발자는 기본 구성 요소를 모방하지만 자체 구현을 제공하는 자체 구성 요소를 제공하는 것을 선호합니다. 다른 한편으로, 기능적으로 완전한 GUI 툴킷을 개발하는 것은 상당한 노력이며 경제적 인 고려 사항은 약간의 우위를 깎을 수 있습니다.

이 문제는 Java에만 국한된 것이 아니라 플랫폼 독립적 툴킷을 생산하는 모든 회사가 직면하고 있습니다.

그것은 역사로 인한 것입니다.

Sun은 모든 Java 소프트웨어가 모든 시스템에서 동일하게 작동하기를 원했습니다.

소프트웨어가 "기본으로"나타나려면 지정된 OS의 다른 소프트웨어와 동일하게 작동해야합니다.

OS와의 통합으로 인해 각 OS에서 소프트웨어가 다르게 작동하므로 Sun은 OS와 통합 된 Java 소프트웨어를 작성하기 어렵게하기 위해 모든 노력을 기울였습니다.

요즘에는 웹 서버 기반 소프트웨어 이외의 다른 것에 관심이있는 Java 프로그래머는 거의 없습니다.

Sun은 Microsoft Java 기반 시스템을 사용하는 모든 프로그래머를 축으로 데스크탑에서 Java를 중단했습니다. 따라서 초기에 Java를 선택하는 모든 프로그래머가 나빠 보이게 만들었습니다.

“기본 모양”에 관심이있는 데스크탑 소프트웨어를 작성하는 사람은 오랫동안 Java를 사용하지 않는 법을 배웠으며 Oracle 소프트웨어를 사용할 때마다 견해가 강화되었습니다.

따라서 요즘에는 Java 프로그래머의 데스크탑 소프트웨어에 "기본 모양"이 필요하지 않습니다.

당신이 생각하는 것은 native실제로 SWT 같은 툴킷은 그 OS의 UI에 대한 게시 된 표준을 준수하면서 자신의 일을하고 네이티브 응용 프로그램입니다. 문제는 아무도 Java 앱을 실행할 때 해당 표준에 따라 앱을 빌드하지 않는다는 것입니다. 네이티브가 아닌 것 같습니다. 예를 들어, 거의 모든 Microsoft 프로젝트 (Office, Outlook 등)는 Windows 표준 컨트롤을 사용하여 시각적으로 재현 할 수 없습니다.

Microsoft와 Apple 모두 OS 플랫폼에 동적 UI 기능을 추가함에 따라 더욱 악화 될 것입니다. 개발자가 웹 디자인에서 웹 사이트 스타일을 만드는 것과 거의 같은 방식으로 앱을 스킨 / 스타일링 할 수 있습니다.

Android 플랫폼의 Java가이 경로를 따르고 있습니다. 스킨 스타일을 사용하여 Android 용 UI 요소를 XML로 정의합니다.

Java는 데스크탑 플랫폼으로 인기가 없었습니다. 결과적으로 업계의 이러한 변경 사항은 데스크톱 런타임으로 전파되지 않습니다. 이 문제를 해결하기 위해 시간을 할애 할 개발자가 충분하지 않습니다.

어떤 운영 체제를 "기본"으로 보시겠습니까?

당신 은 시간의 100 % 그들 모두에게 고유 할 수 없습니다 .

SWT 등은 타협점 에 도달해야 할 때 얻을 수있는 것처럼 모든 것에 고유하게 보이기위한 최선의 노력 입니다.

실제로이 타협은 점점 더 어려워지기 시작합니다. 운영 체제 때문이 아니라 입력 장치 때문입니다. 터치 스크린의 경우 마우스 오른쪽 버튼이 없기 때문에 실제로 다르게 디자인 해야 합니다. 따라서 그렇지 않으면 동일한 기능을 수용해야합니다.

마법없이, guestures에 마우스 오른쪽 버튼에서 "직관적으로"기능을 이동 버튼이 없을 것 당신이 어떤 시점에서, 당신은 당신이 생각 한 모든 플랫폼에 네이티브 (모든 단일 입력 장치에 대한 모든 세부적인 측면을 specifiying, 그럼에도 불구하고 비 -당신이 고려 하지 않은 것에 대한 네이티브 ).

정말 좋은 질문입니다. 나는 지난 몇 년 동안 항상 그것에 대해 궁금해했습니다. 이것 뒤에 정당한 이유가 있다고 생각했지만 실제로는 그렇지 않습니다.

나는 대답이 다소 간단하다고 생각하며 많은 대답이 실제로 문제에 파고 들지 않습니다.

언어가 화면에 piexel을 그릴 수 있다면 Windows 양식 컨트롤 모양과 느낌을 정확하게 모방하는 GUI 프레임 워크를 100 % 만들 수 있습니다.

Java는 크로스 플랫폼이기 때문에 실제 실행중인 시스템 유형 (Mac / Windows) UI를 기반으로 런타임 플랫폼 스타일과 일치하는 두 플랫폼에서 다르게 보일 수 있습니다.

예를 들어 XAML에서 볼 수 있듯이 UI는 매우 구조화 된 형태와 언어로 쉽게 표현할 수 있습니다. 시간이 걸리면 "기본"동작을 선택할 수도 있습니다.

따라서 Java 개발자가 Mac 및 Windows에서 기본으로 보이는 응용 프로그램을 얻을 수있는 GUI 프레임 워크를 만들 수 있습니다.

우리는 Swing에 도달합니다. Java를 위해 생성 될 수있는 잠재적 인 무한한 GUI 프레임 워크 중 하나의 GUI 프레임 워크입니다. 위의 프로세스를 따르지 않고 프로그래밍 된 방식으로 작동하며 두 시스템에서 이상하게 보이는 앱을 얻습니다. 스윙 개발자가 선택한 것은 아무도 그렇게하지 않고 그렇게 행동하도록 강요하지 않았다.