Qt Designer GUI와 직접 코딩 된 GUI

Qt Designer GUI와 직접 코딩 된 GUI

---

나는 휴일에 Qt 응용 프로그램을 작성하는 것을 배우고 있습니다. 몇 시간 전에 Qt Designer에 대해 읽었습니다. Qt에서 실제 응용 프로그램을 작성하는 사람들이 GUI를 디자인하는 데 사용하는 것은 무엇입니까? 실제로 사람들은 일반적으로 GUI를 어떻게 디자인합니까?

복잡한 GUI의 경우 Designer가 의미가 있지만 Qt Designer를 사용하는 것보다 개념적으로 손으로 코드를 작성하는 것이 간단하다는 것을 알았습니다. Designer를 사용하면 큰 GUI가 가능할 수 있지만 시간이지나면서 복잡성이 증가함에 따라 관리하기가 매우 어려워 질 수 있습니다 (이것은 제 생각입니다). 또한 AmaroK 소스 코드를 다운로드하여 그 사람들이하는 일을 들여다 보았고 addWidget () 및 친구들에 대한 많은 호출을 찾았지만 Designer가 만든 XML 파일은 없었습니다. 모든 플랫폼).

그렇다면 GUI를 만드는 "올바른"방법은 무엇입니까? 디자이너 또는 코드? 이 논의를 위해 다음 유형의 GUI를 고려해 보겠습니다.

1. 입력 만하면되는 간단한 대화 상자에 결과가 표시되고 종료됩니다. YouTube URL을 가져 와서 비디오를 사용자의 하드 디스크로 다운로드하는 응용 프로그램을 가정 해 봅시다. 초보자가 시작할 수있는 응용 프로그램의 종류.
2. 예를 들어 툴바 / 메뉴 항목이 몇 개있는 스티커 메모 편집기와 같은 중간 레벨 GUI. xPad를 예로 들어 보겠습니다 ( http://getxpad.com/ ). 대부분의 응용 프로그램은 "유틸리티"범주에 속한다고합니다.
3. AmaroK 또는 OpenOffice와 같은 매우 복잡한 GUI. 당신은 그들이 당신의 눈을 피가 나게 만들기 때문에 그들을 알고 있습니다.

---

Qt3에서 Designer에 대한 경험을 시작했습니다.

Qt3

이 시점에서 Designer는 주로 응용 프로그램으로 컴파일 할 코드를 생성하는 데 유용했습니다. 우리는 그 목적으로 사용하기 시작했지만 생성 된 모든 코드를 사용하면 일단 편집 한 후에는 편집 내용을 잃지 않고 더 이상 돌아가서 다시 생성 할 수 없습니다. 우리는 생성 된 코드를 가져 와서 수작업으로 모든 것을 수행했습니다.

Qt4

Qt4는 Designer에서 크게 향상되었습니다. 더 이상 코드 만 생성하지는 않지만 Designer 파일 (xml)을 동적 으로로드 하여 프로그램의 실행중인 개체에 동적으로 연결할 수 있습니다. 그러나 생성 된 코드는 없지만 Designer에서 항목의 이름을 지정해야합니다. 코드를 손상시키지 않는 이름으로.

내 평가에 따르면 Mac OS X의 Interface Builder만큼 유용하지는 않지만 프로그램에서 Designer 파일을 직접 사용하는 것을 볼 수 있습니다.

Qt3 이후로 Designer로 다시 이동하지는 않았지만 여전히 레이아웃을 프로토 타입 및 디버그하는 데 사용합니다.

문제의 경우 :

1. Qt가 제공하는 표준 대화 상자를 사용하여 벗어날 수 있습니다. QInputDialog 또는 QDialog를 서브 클래 싱하는 경우 QButtonDialogBox 를 사용하여 버튼에 적절한 플랫폼 레이아웃이 있는지 확인하십시오.

2. 디자이너 기능이 제한적인 xPad와 같이 더 제한적인 작업을 수행 할 수 있습니다.

3. 디자이너만으로 OpenOffice와 같은 것을 작성할 수는 없다고 생각하지만 그게 요점이 아닙니다.

텍스트 편집기와 마찬가지로 Designer를 다른 도구로 사용하고 싶습니다. 제한 사항을 찾으면 새로운 문제에 대한 다른 도구를 사용해보십시오. 디자이너의 장점 중 하나는 프로그래머가 아닌 다른 사람이 레이아웃을 수행 할 수 있다는 점입니다.

---

Qt Designer 및 기타 툴킷 / UI 도구에 대한 경험 :

• UI 도구는 작업 속도를 높입니다.
• UI 도구를 사용하면 나중에 레이아웃을 쉽게 조정할 수 있습니다.
• UI 도구를 사용하면 프로그래머가 아닌 사용자도 UI 디자인 작업을보다 쉽게 ​​/ 할 수 있습니다.

디자인을 여러 UI 파일로 분할하여 UI 도구에서 복잡성을 처리 할 수있는 경우가 많습니다. 각 파일에 작은 논리적 구성 요소 그룹을 포함시키고 각 그룹을 완전한 UI를 빌드하는 데 사용되는 단일 위젯으로 취급하십시오. Qt Designer의 승격 위젯 개념이이를 지원할 수 있습니다.

프로젝트 규모에 차이가 있다는 것을 발견하지 못했습니다. 경험이 다를 수 있습니다.

UI 도구로 만든 파일 (실제로 원한다면 직접 작성할 수있을 것 같음)은 종종 런타임에 동적으로로드 될 수 있습니다 (Qt 및 GTK +는이 기능을 제공합니다). 즉, 레이아웃을 변경하고 다시 컴파일하지 않고도 테스트 할 수 있습니다.

궁극적으로 원시 코드와 UI 도구가 모두 효과적 일 수 있다고 생각합니다. 환경, 툴킷 / UI 도구 및 개인 취향에 따라 크게 달라질 수 있습니다. UI 도구는 빠르게 작동하고 나중에 쉽게 변경할 수 있기 때문에 UI 도구를 좋아합니다.

---

내가 일하는 조직은 몇 년 전 GUI 응용 프로그램을 Qt로 이식했습니다. 언급 할 가치가있는 몇 가지 측면이 있다고 생각합니다.

• 적어도 그 시점에서 Qt Designer로 작업하는 것은 현실적인 옵션이 아닙니다. Qt Designer로 수행 할 수없는 기능이 너무 많았습니다.
• 보존되어야하는 관습과 구조는 Qt Designer의 사용을 방해했습니다.
• Designer없이 시작한 후에는 다시 돌아 가기가 어려울 수 있습니다.
• 그러나 가장 중요한 측면은 프로그래머가 GUI IDE를 사용하는 대신 vi 또는 emacs를 사용하여 프로그래밍하는 데 매우 많이 사용되었다는 것입니다.

내 경험은 다시 돌아갑니다. Qt3.3을 사용하는 4 년은 Designer에서 대화 상자의 동적 동작을 실현할 수 없었습니다.

---

Qt Designer를 사용하지 않고 Qt Designer를 사용하지 않고 Qt에서 복잡한 GUI를 작성하고 유지 관리했다고 말하면 Qt Designer를 좋아하지 않기 때문에 결코 그런 식으로 일하지 않았습니다.

Qt로 시작했을 때 Dreamweaver와 Frontpage 및 기타 시각적 HTML 도구에 대한 끔찍한 경험이 있었으며 HomeSite로 코드를 작성하고 까다로운 레이아웃을 위해 Photoshop을 사용하는 것이 훨씬 낫습니다. 문제.

비주얼 코드 IDE를 사용하면 비주얼 도구 내에 유지하려고하지만 이해하기 어려운 방식으로 코드를 조정해야 할 위험이 있습니다.

예를 들어, iPhone 개발을 배우는 것은 '매직'시각적 요소 ( '연결 관리자의 빈 원에서 인터페이스 빌더 창의 객체로 드래그 ...')를 누르는 것이 좌절감을 느꼈습니다. 나) 평범한 오래된 코드로 이해하십시오.

Qt와 함께 행운을 빈다-훌륭한 툴킷이지만, 그것을 사용하면 Qt Creator는 훌륭한 IDE 인 것처럼 보입니다.

---

I'd add that one of the reasons for using graphical designer was the lack of layout managers in Win32, for instance. Only absolute positioning was possible, and doing that by hand would have just sucked.

Since I switched from Delphi to Java for GUI apps (back in 2002), I've never used designers any more. I like layout managers much more. And yeah, you get boilerplate code, but moving objects on a UI designer may take as much time as changing the boilerplate. Plus, I would be stuck with a slow IDE; that's for the Java/C# case, OK, while for Qt (especially Qt4) it doesn't apply. For Qt3, I wonder why one should edit the generated code - wasn't it possible to add code in other files? For which reason?

About the discussed cases: 1) Hand Coded GUI is likely faster to write, at least if you know your libraries. If you're a newbie and you don't know them, you may save time and learn less with a designer, since you don't need to learn the APIs you use. But "learn less" is the key factor, so in both cases I'd say Hand Coded GUI.

2) Menu bars are quite annoying to write code for. Also, think to details like accelerators and so on. Still, it depends on what you're used to. After some time, it may be faster to type that boilerplate than to point-and-click into designer to fix all those properties, but just if you can really type like into a typewriter (like those admins for which typing Unix commands is faster than using any GUI).

3) I'd extend the answer for case #2 to this one. Note that, for Win32 platforms, it may be possible that using designers which generate Win32 resources might be faster to load (no idea about that).

However, I'd like to mention a potential problem with using Qt Designer there. Real world case: it took some seconds (say 10) to load a complex Java dialog (the Preferences dialog box for a programmer's text editor) with a lot of options. The correct fix would have been to load each of the tabs only when the programmer wanted to see them (I realized that after), by adding a separate method to each preference set to build its GUI.

If you design all the tabs and the tab switcher together with a designer, can you do that as easily? I guess there might be a similar example where a hand coded GUI gives you more flexibility, and in such a big app, you're likely to need that, even if just for optimization purposes.

---

One of the main benefits of using designer to create GUIs is that other programmers can change or maintain forms and widgets easily without the need to delve in to a complex code.

---

Its strange that you're saying the writing code is simpler than manipulating objects in a graphical environment. It's a no-brainer.
The designer is there to make your life easier and in the long term it makes your code more maintainable. It's easier looking in the designer to see what the your UI looks like then reading the code and trying to imagine what it might look like.
With current Qt you can do almost everything from within the designer and the very few things you can't do, you can fix with very few lines of code in the constructor. Take for instance the simplest example - adding a signal-slot connection. Using the designer it's as simple as a double click. Without the designer you need to go lookup the correct signature of the signal, edit the .h file and then edit write your code in the .cpp file. The designer allows you to be above these details and focus on what really matters - the functionality of your application.

---

I like to first turn to the designer to develop GUI widgets. As mentioned in the other posts, its faster. You also get immediate feedback to see if it "looks right" and isn't confusing to the user. The designer is a major reason I choose Qt over other toolkits. I mostly use the designer to make the one-off dialogs.

Having said that, I do the main window and any complex widgets by hand. I think this is the way Trolltech intended. QFormLayout is a class they provide to easily programatically create an input dialog.

By the way, the designer in Qt 4 is not an IDE like the one they had in Qt 3. It's just an editor for editing .ui files. I like it that way. The new cross platform IDE is going to be called Qt Creator.

---

It's an old post but I would advise you to look at Clementine - a music player which (I think) derives from Amarok. They use Qt4 and from what I can see there is a ui folder in the src folder of the project. In the ui folder as one might expect they have all sorts of .ui files. If you compile and start Clementine you will see that the GUI is fairly complex and quite nice.

---

For me, it depends how much logic is encapsulated in the widget/GUI. If it's just about simple forms, I prefer to use QtDesigner.

If it contains complex checks or interaction, I tend to program it.

---

We're using the Qt Designer if anyone needs to create a Gui.
The thing is to create just little Widgets for certain tasks (like you would do in a class-design) and then get them together into a "parent-gui".

This way your widgets are highly reusable and could be used for Guis in a modular way. You just have to specify which signals each Widget is sending and which slots they provide.

We additionally are creating .ui-Files which than could be generated during build-process. Until now there was no need to edit those files by hand.

---

Build different parts of your UI
in different .ui files using QtDesigner,
then bring them together (and add complications) in code.

There are things you can't do in Qt Designer, you can only do in code,
so Qt Designer is just one (great) part of the tool chain.

참고URL : https://stackoverflow.com/questions/387092/hand-coded-gui-versus-qt-designer-gui