2009-03-08 2 views
13

gui-designer 도구를 사용하는 경우와 비교하여 Java 또는 Qt를 C++과 함께 사용하는 경우 GUI 작성에 대한 의견을 듣고 싶습니다. GUI 디자이너 도구의 예로는 MFC GUI 디자이너, Qt 디자이너, Interface Builder (Apple)가 있습니다.수공 코드 GUI 또는 gui-designer 도구 사용

나는 손으로 코딩하는 팬 이었지만 최근의 경험에서 나는 전환했다. 필자가 손으로 코딩 한 문제는 GUI를 작성하는 것이 매우 빠르고 유연하다는 것입니다.하지만 일단 오래 전에 작성된 GUI를 변경해야 할 경우 매우 어려울 수 있습니다. 큰 패널에서 올바른 요소를 찾는 것은 어려울 수 있습니다.

두 번째 문제는 GUI 작성 및 레이아웃 코드에 많은 로직을 추가하기가 너무 쉽다는 것입니다. 나는 GUI 코드의 유지 보수를 인계 받아야했다. 재사용하기가 정말 어렵다. 왜냐하면 그 동작이 모양과 혼합되어 레이아웃과 동작이 혼합되어 클래스가 매우 커지고 이해하기 어렵 기 때문이다.

GUI 디자이너 도구를 사용하면 내보기에서 모양과 논리를 훨씬 더 명확하게 구분할 수 있습니다.

답변

4

GUI를 직접 코딩하는 대신 인터페이스 빌더를 사용해야한다고 생각합니다. 언급 한 질문에서와 같이 훨씬 더 명확한 분리가 이루어지며 일단 편집해야하는 것이 훨씬 쉬워집니다.

Qt는 디자이너는 .ui 파일 1)에서 클래스를 만들려면이 기능을 가지고,하지만 난이 단지 더 전혀 존재하지 않아야하는 코드 생성으로이 기능을 사용하지 않는 것이 가장 좋은 방법이라고 생각 . .ui - 파일에서 창을 만드는 속도 문제는 무시할 수 있습니다. 창을 한 번만로드해야하기 때문입니다.

이 PyQt는하지만, 비슷한는 C 가능하다 ++ :

class SelectDateDialog(QDialog): 
    def __init__(self): 
     QDialog.__init__(self) 
     uic.loadUi("resources/SelectDate.ui", self) 

는 본질적으로 이것은 __init__() 방법으로 모든 UI 코드를 포함하는 것과 같은 효과가 있지만, UI가 거의 완전히 분리되어 암호.

1).ui 파일은 일부 비표준 기능을 UI 당신에 포함하려는 경우

+0

예 Qt를 사용할 때 선호하는 방법입니다. 매우 동적 인 UI 코드를 건네지 만, 나머지는 디자이너에게 충실하려고 노력할 것입니다. 라이브러리 변경에 따른 변환 및 XML 파일은 GUI를 설명하는 C++ 코드를 변환하는 것보다 훨씬 빠릅니다. –

2

상황에 따라 다릅니다. 나는 둘 다 그들의 자리를 가지고 있다고 생각하며, 나는 보통 하이브리드 접근법을 사용한다.

GUI 빌더가 수행 할 수없는 작업이 항상 있습니다 (예 : Interface Builder에서 색상을 UIColor 상수로 설정). 반면에 UI 작업의 대부분은 매우 평범한 것입니다 (예 : 정적 라벨 추가).

나는 GUI 빌더에서 평범한 것을하고 코드에서 흥미로운 것을 선호한다.

또한 GUI 빌더 (인터페이스 빌더 및 제 경우에는 글 레이드)가 작성한 XML을 직접 편집하는 경우가 있습니다.

+0

GUI와 같이 쉽게 읽을 수있는 것으로 GUI를 정의해야한다고 생각합니다. 필요한 경우 손으로 변경할 수 있습니다. 예를 들어 XML에 비해 XML의 이점. C++ 코드는 디자이너가 쉽게 구문 분석 할 수 있다는 것입니다. –

3

재미있는만큼 나를 위해 다른 방향으로 갔다. Winforms의 관점에서 말하면, 디자이너가 생성 한 코드는 상당히 시끄럽다. 아마도 모든 속성 설정 중 4 분의 1 또는 절반이 실제로 필요하다. 꽤 큰 컨트롤을 만드는 것은 디자이너와 작업 할 때 유혹이됩니다. Winforms 디자이너의 컨트롤 계층 구조를 변경하면 내 눈에는 상당히 악몽입니다.

내 마지막 프로젝트에서는 선언적 방식으로 양식, dockmanagers, 메뉴, 툴바 등에서 스플리터를 설정하는 추가 API를 만들었습니다. 이들은 우려의 분리를 더욱 강요 할 것입니다.

또한 자동 레이아웃 기능에 더 많이 의존하려고합니다.이 기능은 WPF에서 훨씬 좋지만 Windows Forms에서도 사용할 수 있습니다.

+0

빌더를 사용하여 발생하는 소음에 대한 귀하의 의견에 완전히 동의합니다. 이것은 Java에도 해당됩니다. 일반적으로 수십 개의 JLabel이 클래스의 필드로 끝나지 만 실제로는 필요하지 않습니다. –

+0

디자이너가 생성 한 노이즈는 해당 코드를 블랙 박스로 취급 할 수 있고 어떤 방식 으로든 직접 편집 할 필요가 없다고 생각합니다. 바람직하게는, GUI는 마크 업 언어를 파싱함으로써 런타임시에 구축되어야한다. 예 : XAML, XUL (firefox) 또는 Qt 디자이너 XML과 같은 XML –

0

이의 내보기 : 1. 손으로 코딩 GUI 코드가 훨씬 더 재사용 2. 레이아웃 문제는 내가 강하게 당신에 의해 그 일을 OS X의에 인터페이스 빌더를 사용하여 조언을 것

3

디자이너와 간단하다 배우고 싶다면 손이 괜찮지 만, 실제 프로젝트에서 사용하면 두통을 많이 줄일 수 있습니다. 정말 강력합니다.

Java 및 C++의 경우 수행중인 작업과 플랫폼에 따라 다릅니다. 간단한 애플리케이션의 경우 UI 코드가 전혀 표시되지 않습니다. 그러나 복잡한 응용 프로그램과 리치 클라이언트의 경우 일반적으로 일부 코드를 수동으로 수행해야합니다.

15

내가 항상 손으로 코드 것 (Java와 마찬가지로) 표준 (또는 사실상 표준) GUI 마크 업 언어가없는 GUI 디자인. 그 이유는 GUI 빌더 디자인 도구를 사용하면 특정 IDE를 사용할 수 있다는 것입니다. 시간이 지남에 따라 GUI 디자인 및/또는 코드 작성을위한 최상의 IDE가 변경 될 것이며 각 개발자는으로 가장 편한 IDE를 자유롭게 선택할 수 있어야합니다.

내가 지금 일하고있는 곳에서 우리는 NetbeansMatisse GUI 빌더를 사용하여 작성된 많은 레거시 GUI를 가지고 있습니다 (당시의 조언 :-). 모든 개발자가 IDE로 IntelliJ IDEA 또는 Eclipse을 선호하기 때문에 현재는 거의 유지할 수 없습니다. 개발자가 GUI 레이아웃 (사람들이 Netbeans 프로젝트 정의를 동기화 상태로 유지하지 못하게)을 수정하기 위해 Netbeans를 시작하게하는 것은 현실적이지 않거나 실행 가능하지 않습니다.

또 다른 요점은 입니다. GUI 레이아웃 코드를 쓰는 총 시간은 주어진 프로젝트의 총 개발 작업의 5 % 일 것입니다. 코드를 직접 작성하는 데 2 ​​배의 시간이 걸리지 만, 이것은 사물의 웅장한 계획에서 오버 헤드를 많이 번역하지 않습니다. 그리고 장기간 유지 보수 비용을 지불하는 데는 적은 비용이 듭니다.

비즈니스 로직에서 GUI 레이아웃 로직을 분리하는 것이 확실한 한, 결과적으로 어떤 것도 고통스럽지는 않습니다. 아무도 GUI 빌더를 더 이상 사용하지 않습니다!

+2

저는 이것이 GUI 디자이너들에 대한 적절한 논쟁이라고 생각하지 않습니다. 이것은 Java IDE가 일반적으로 GUI 디자인을 수행하는 방식에 대한 논쟁입니다. GUI는 일부 마크 업 언어로 저장되어야하며 런타임에 생성되므로 유지 보수가 불가능한 생성 코드로 끝나지 않습니다. 또는 uic과 함께 Qt를 좋아하십시오. –

+1

전적으로 동의합니다. Java에 IDE 독립적 인 GUI 마크 업 (표준 또는 사실상 표준)이있는 경우이를 사용하면 기쁠 것입니다. 나는 여전히 GridBaglayout으로 같은 결과를 얻을 수 있다고 생각한다 :-) –

+0

오. 좋은 의견과 좋은 생각 :) – hqt

6

나는 손으로 작업하기 때문에 주변에서 물건을 섞어서 응용 프로그램 내에서 패널을 재사용하는 것이 훨씬 쉽습니다 (일부 패널은 여러 곳에 나타날 수 있음).

디자이너를 사용하면 팀에서 작업 할 때 아티스트가 GUI를 사용해야합니다.

큰 패널에서 올바른 요소를 찾는 것이 어려울 수 있습니다.

?? 나는 그것을 본 적이 없다.

+0

레이아웃 관리자, 하위 위젯, 탭 등의 여러 레이어에 넣어 50 개 이상의 요소가있는 패널 있어요. 그리고 당신은 한 레이아웃 관리자에서 다른 요소를 이동해야합니다. 올바른 레이아웃 관리자를 찾는 데 문제가 없었습니까? 아,이 패널을 코딩하지 않았습니다. 다른 누군가가 그랬다. –

+1

불가능하다고 말하는 것은 아닙니다. (제 경험상) 드문 것입니다. 아마도 레이아웃을 반영하기 위해 GUI 코드를 들여 쓰기 때문일 수 있습니다. 때로는 간단한 것들이 가장 도움이됩니다. –

+2

@ Adam 그것은 나에게 나쁜 코드처럼 들린다. – Draemon

1

나는 올바른 대답이 대상 플랫폼의 문화에 달려 있다고 생각하는 경향이 있습니다. OS X에서 인터페이스 빌더는 툴 체인의 필수적인 부분이므로이를 피하기 어렵습니다.

자바 (awt 또는 스윙)에서는 그 반대가 사실입니다. 이를위한 툴체인 지원은 없습니다.

정말 당신이 말할 수있는 방법은 도구가 출력물을 만드는 방식입니다. Interface Builder는 코코아가 화면에 컨트롤을 두는 방식에 특정한 .nib 형식 파일을 생성합니다. 본질적으로 인터페이스 마크 업 형식을 이해합니다. Java에는 이와 유사한 개념이 없습니다. 모든 것은 컴파일 된 클래스이므로 편리한 결과를 얻는 것이 훨씬 어렵습니다.

GTK +는 글레이드와 결합 할 때 두 가지 사이의 적절한 균형을 맞추는 것처럼 보입니다.

1

두 가지 방법을 혼용하지 마십시오. 나는 종종 GUI 디자이너에서 폼의 기본 레이아웃을 만든다. (빨리 그리고 당신이하는 일을 볼 수 있기 때문에) 하나 이상의 패널에 코드를 입력한다. 이는 GUI가 특정 상황에 적응해야 할 때 특히 유용합니다. 예를 들어 연결된 하드웨어에 따라 GUI를 변경해야하는 경우입니다.

어쨌든 가장 중요한 것은 사실 GUI와 응용 프로그램 로직을 분리 된 상태로 유지하는 것입니다.

0

핸드 코딩이 잘 될 수있는 사용자 인터페이스를 설명하는 XML 파일입니다. 유연성은 더 높지만 Java/C++ 언어는 UI 디자인을 타깃으로하는 것이 아니기 때문에 좋은 인터페이스를 만드는 데 더 많은 시간을 투자해야합니다.

리비전 컨트롤이있는 경우 변경 기록, 바이너리 형식을 사용하는 설계로 수행 할 수없는 작업 또는 RCS와 호환되지 않는 XML 형식을 볼 수 있습니다.

오늘 UI를 시각적으로 디자인하는 데 사용할 수있는 도구의 대부분에는 몇 가지 기능이 없습니다. 그것들은 충분히 융통성이 없으며, 어떤 특징들은 그것들을 코딩 할 때에 만 얻을 수 있습니다. 또한 경우에 따라 생성 된 코드는 실제로 사람에게 친숙하지 않으며 직접 수정하면 더 이상 디자이너를 계속 사용할 수 없게됩니다.

하지만 설계가 간단하면 설계가 실제로 시간을 절약 할 수 있으며 설계자가 앞으로 개선 될 것이라는 희망을 가질 수 있습니다. 그러나 나는 폭넓게지지하지 않을 것입니다.

내 결론은 오늘 융통성이 필요한 경우 인터페이스를 손으로 코딩해야한다는 것입니다. 간단하고 빠른 것을 원하면 디자이너가 최선의 선택입니다.

아마도 미래에는 디자이너가 더 강력해질 것입니다. 아니면 XUL 또는 XAML과 같은 C++/Java에서 사용하기에 더 적합한 UI 디자인에 특화된 새로운 언어가있을 것입니다.

2

많은 항목 양식과 표 형식 데이터로 비즈니스 응용 프로그램을 디자인하는 경우 UI 디자이너를 사용하는 것보다 UI 작성 코드가 더 빠르고 유지 보수가 쉽습니다. 이러한 종류의 응용 프로그램에서는 화면에서 미리 정의 된 위치에 하나의 요소를 정확하게 배치 할 필요가 거의 없지만 다른 방법으로 추출 할 수있는 많은 반복 및 디자인 규칙이 있습니다.

Eclipse 또는 OpenOffice 환경 설정 대화 상자를 예로 들어보십시오. 여러 종류의 카테고리와 각기 다른 옵션을 설정할 수 있습니다. 당신이 그 크기의 것을 만들어야한다면, 각 화면을 디자인하는 손이 평범한 작업입니다. 몇 가지 규칙과 기본값에 따라 제공된 도메인 데이터에서 UI 요소를 즉석에서 생성하는 코드를 작성하는 것이 훨씬 더 나은 방법입니다.

디자이너를 사용하면 비즈니스 로직을 이미 UI에서 벗어나게하는 방법으로 분리가 어떻게 도움이되는지 이해하지 못합니다.

자바를 사용하는 경우 마지막으로 MigLayout을 확인하십시오. 그것은 Swing과 SWT에서 작동합니다. 구문은 매우 간결하고 명확하며, 믿을 수 없을 정도로 유용한 디버그 모드를 가지고 있습니다.

+0

매우 동적 인 GUI의 경우에 동의합니다. 모델 데이터에서 생성 될 수있는 것들은 손으로 코딩하는 것이 좋습니다. 그러나 나는 그것이 특별한 경우라고 생각한다. –

+0

당신이 일하고있는 틈새 시장에 달려 있다고 생각합니다. 대다수의 UI를 손으로 코딩하는 것이 훨씬 더 적합합니다 : 거래 및 지불 데이터의 행과 행, 다양한 옵션의보고, 추가/옵션 변경 등. – javashlook