Ręcznie kodowany graficzny interfejs użytkownika a graficzny interfejs użytkownika Qt Designer [zamknięty]

Te wakacje spędzam ucząc się pisać aplikacje Qt. Czytałem o Qt Designer zaledwie kilka godzin temu, co sprawiło, że zacząłem się zastanawiać: czego ludzie piszący rzeczywiste aplikacje w Qt używają do projektowania swoich GUI? W rzeczywistości, jak ludzie ogólnie projektują GUI?

Ja, na przykład, odkryłem, że ręczne pisanie kodu jest koncepcyjnie prostsze niż używanie Qt Designer, chociaż dla złożonych GUI Designer może mieć sens. Duże GUI mogą być możliwe za pomocą Designer, ale z czasem mogą stać się bardzo trudne w zarządzaniu, gdy wzrasta złożoność (to tylko moja opinia). Pobrałem również kod źródłowy AmaroK, aby rzucić okiem na to, co robili ci faceci, i znalazłem wiele wywołań addWidget () i przyjaciół, ale żaden z tych plików XML utworzonych przez Projektanta (poza tym: AmaroK musi być moją ulubioną aplikacją w historii dowolna platforma).

Jaki jest zatem „właściwy” sposób tworzenia GUI? Projektant czy kod? W tej dyskusji rozważmy następujące typy GUI:

1. Proste okna dialogowe, które wystarczy wprowadzić, pokazać wynik i wyjść. Załóżmy, że aplikacja pobiera adres URL serwisu YouTube i pobiera wideo na dysk twardy użytkownika. Rodzaj aplikacji, z którymi prawdopodobnie zacznie nowicjusz.
2. Interfejsy GUI na poziomie średnio zaawansowanym, takie jak, powiedzmy, edytor notatek z kilkoma paskami narzędzi / elementami menu. Weźmy na przykład xPad ( http://getxpad.com/ ). Powiedziałbym, że większość aplikacji należy do kategorii „narzędzi”.
3. Bardzo złożone GUI, takie jak AmaroK czy OpenOffice. Znasz je, kiedy je widzisz, ponieważ krwawią ci oczy.

Nasze doświadczenie z Projektantem zaczęło się w Qt3.

Qt3

W tym momencie Designer był przydatny głównie do generowania kodu, który następnie kompilowałbyś do swojej aplikacji. Zaczęliśmy używać w tym celu, ale z całym wygenerowanym kodem, po edycji, nie możesz już wrócić i wygenerować go ponownie bez utraty edycji. Skończyło się na tym, że wzięliśmy wygenerowany kod i odtąd robiliśmy wszystko ręcznie.

Qt4

Qt4 znacznie poprawił się w Designer. Już nie generuje tylko kodu, ale możesz dynamicznie ładować pliki Projektanta (w formacie XML) i dynamicznie łączyć je z uruchomionymi obiektami w programie - nie ma generowanego kodu, jednak musisz nazwać elementy w Projektancie i przykleić z imionami, aby nie łamać kodu.

Moja ocena jest taka, że ​​nie jest tak przydatny jak Interface Builder w systemie Mac OS X, ale w tym momencie mogłem zobaczyć użycie plików Designer bezpośrednio w programie.

Nie wróciliśmy do Projektanta od czasu Qt3, ale nadal używamy go do tworzenia prototypów i debugowania układów.

W przypadku Twoich problemów:

1. Prawdopodobnie możesz uciec przy użyciu standardowych okien dialogowych, które oferuje Qt. QInputDialog lub jeśli tworzysz podklasę QDialog, upewnij się, że używasz QButtonDialogBox, aby upewnić się, że przyciski mają odpowiedni układ platformy.

2. Prawdopodobnie mógłbyś zrobić coś bardziej ograniczonego, jak xPad z ograniczoną funkcjonalnością Projektanta.

3. Nie sądzę, że można napisać coś takiego jak OpenOffice wyłącznie z Projektantem, ale może nie o to chodzi.

Użyłbym Projektanta jako innego narzędzia, tak jak twojego edytora tekstu. Gdy znajdziesz ograniczenia, wypróbuj inne narzędzie do rozwiązania tego nowego problemu. Całkowicie zgadzam się ze Stevem S., że jedną z zalet Projektanta jest to, że ktoś inny, kto nie jest programistą, może wykonać układ.

Z mojego doświadczenia z Qt Designer i innymi narzędziami / narzędziami UI:

• Narzędzia UI przyspieszają pracę.
• Narzędzia interfejsu użytkownika ułatwiają późniejsze modyfikowanie układu.
• Narzędzia interfejsu użytkownika ułatwiają / umożliwiają nieprogramistom pracę nad projektem interfejsu użytkownika.

Ze złożonością często można sobie radzić w narzędziu interfejsu użytkownika, dzieląc projekt na wiele plików interfejsu użytkownika. Uwzględnij małe logiczne grupy komponentów w każdym pliku i traktuj każdą grupę jako pojedynczy widget używany do tworzenia pełnego interfejsu użytkownika. Pomóc w tym może koncepcja promowanych widżetów Qt Designer.

Nie stwierdziłem, że skala projektu ma znaczenie. Twoje doświadczenie może się różnić.

Pliki utworzone za pomocą narzędzi interfejsu użytkownika (wydaje mi się, że można by je napisać ręcznie, gdybyśmy naprawdę chcieli) często mogą być ładowane dynamicznie w czasie wykonywania (oba Qt i GTK + zapewniają tę funkcję). Oznacza to, że możesz wprowadzać zmiany w układzie i testować je bez ponownej kompilacji.

Ostatecznie uważam, że zarówno surowy kod, jak i narzędzia interfejsu użytkownika mogą być skuteczne. Prawdopodobnie zależy to w dużej mierze od środowiska, zestawu narzędzi / narzędzia interfejsu użytkownika i oczywiście osobistych preferencji. Lubię narzędzia UI, ponieważ szybko mnie uruchamiają i pozwalają na łatwe zmiany później.

Organizacja, dla której pracuję, kilka lat temu przeportowała swoją aplikację GUI na Qt. Myślę, że jest kilka aspektów, o których warto wspomnieć:

• Praca z Qt Designer, przynajmniej w tym momencie, nie była realistyczną opcją: było zbyt wiele funkcji, których nie można było zrobić z Qt Designer;
• Konwencje i struktura, które musiały zostać zachowane, uniemożliwiły użycie Qt Designer;
• Gdy zaczniesz bez Projektanta, prawdopodobnie trudno będzie do niego wrócić;
• Jednak najważniejszym aspektem było to, że programiści byli bardzo przyzwyczajeni do programowania przy użyciu vi lub emacs, zamiast używania GUI IDE.

Moje własne doświadczenie, które sięga ok. Przez 4 lata, używając Qt3.3, dynamiczne zachowanie w oknach dialogowych nie było możliwe do zrealizowania w Projektancie.

Powiem tylko, że napisałem i utrzymywałem złożone GUI w Qt bez używania Qt Designer - nie dlatego, że nie lubię Qt Designer, ale dlatego, że nigdy nie pracowałem w ten sposób.

To po części kwestia stylu i tego, skąd pochodzisz: kiedy zaczynałem na Qt, miałem okropne doświadczenia z Dreamweaver i Frontpage oraz innymi wizualnymi narzędziami HTML, a zdecydowanie wolałem pisać kod za pomocą HomeSite i uciekać się do Photoshopa w celu uzyskania skomplikowanego układu problemy.

Istnieje niebezpieczeństwo związane ze środowiskiem IDE z kodem wizualnym, które starasz się zachować w narzędziach wizualnych, ale w końcu musisz również modyfikować kod - w niezbyt dobrze zrozumiały sposób.

Na przykład, ucząc się programowania iPhone'a, stwierdziłem, że frustrujące jest klikanie `` magicznych '' wizualnych rzeczy (`` przeciągnij z pustego koła w Inspektorze połączeń do obiektu w oknie Interface Builder ... ''), które byłoby prostsze (dla ja), aby zrozumieć zwykłym starym kodem.

Powodzenia z Qt - to świetny zestaw narzędzi, jakkolwiek go używasz, a Qt Creator wygląda na świetne IDE.

Dodam, że jednym z powodów używania projektanta graficznego był na przykład brak menedżerów układu w Win32. Możliwe było tylko pozycjonowanie absolutne, a zrobienie tego ręcznie byłoby po prostu do niczego.

Odkąd przeszedłem z Delphi na Javę dla aplikacji GUI (w 2002), nigdy więcej nie korzystałem z projektantów. O wiele bardziej lubię menedżerów układu. I tak, otrzymujesz standardowy kod, ale przenoszenie obiektów w projektancie interfejsu użytkownika może zająć tyle samo czasu, co zmiana schematu. Poza tym utknąłbym z wolnym IDE; to jest dla przypadku Java / C #, OK, podczas gdy dla Qt (zwłaszcza Qt4) nie ma zastosowania. W przypadku Qt3 zastanawiam się, po co edytować wygenerowany kod - czy nie można było dodać kodu w innych plikach? Z jakiego powodu?

O omawianych przypadkach: 1) Ręczne kodowanie GUI jest prawdopodobnie szybsze do napisania, przynajmniej jeśli znasz swoje biblioteki. Jeśli jesteś nowicjuszem i ich nie znasz, możesz zaoszczędzić czas i nauczyć się mniej z projektantem, ponieważ nie musisz uczyć się interfejsów API, których używasz. Ale „naucz się mniej” jest kluczowym czynnikiem, więc w obu przypadkach powiedziałbym ręcznie kodowane GUI.

2) Paski menu są dość denerwujące przy pisaniu kodu. Pomyśl też o szczegółach, takich jak akceleratory i tak dalej. Jednak zależy to od tego, do czego jesteś przyzwyczajony. Po pewnym czasie może być szybsze wpisanie tego standardowego szablonu niż wskazywanie i klikanie w projektanta, aby naprawić wszystkie te właściwości, ale tylko wtedy, gdy naprawdę możesz pisać jak na maszynie do pisania (jak ci administratorzy, dla których pisanie poleceń Uniksa jest szybsze niż za pomocą dowolnego GUI).

3) Rozszerzyłbym odpowiedź dla przypadku nr 2 na ten. Zauważ, że w przypadku platform Win32 może się zdarzyć, że użycie projektantów, którzy generują zasoby Win32, będzie ładować się szybciej (nie mam o tym pojęcia).

Chciałbym jednak wspomnieć o potencjalnym problemie z używaniem tam Qt Designer. Przypadek ze świata rzeczywistego: załadowanie złożonego okna dialogowego Java (okno dialogowe Preferencje dla edytora tekstu programisty) z wieloma opcjami zajęło kilka sekund (powiedzmy 10). Prawidłową poprawką byłoby ładowanie każdej z zakładek tylko wtedy, gdy programista chciałby je zobaczyć (zdałem sobie z tego sprawę później), dodając oddzielną metodę do każdego zestawu preferencji, aby zbudować jego GUI.

Jeśli projektujesz wszystkie karty i przełącznik kart wspólnie z projektantem, czy możesz to zrobić równie łatwo? Wydaje mi się, że może istnieć podobny przykład, w którym ręcznie zakodowany graficzny interfejs użytkownika zapewnia większą elastyczność, aw tak dużej aplikacji prawdopodobnie będziesz tego potrzebować, nawet jeśli tylko do celów optymalizacji.

Jedną z głównych zalet używania projektanta do tworzenia GUI jest to, że inni programiści mogą łatwo zmieniać lub utrzymywać formularze i widżety bez konieczności zagłębiania się w złożony kod.

To dziwne, że mówisz, że pisanie kodu jest prostsze niż manipulowanie obiektami w środowisku graficznym. To nie myślenia.
Projektant jest po to, aby ułatwić Ci życie, a na dłuższą metę sprawi, że Twój kod będzie łatwiejszy w utrzymaniu. Łatwiej jest zajrzeć do projektanta, aby zobaczyć, jak wygląda Twój interfejs użytkownika, niż przeczytać kod i spróbować wyobrazić sobie, jak może wyglądać.
Z obecnym Qt możesz zrobić prawie wszystko z poziomu projektanta, a kilka rzeczy, których nie możesz zrobić, możesz naprawić za pomocą bardzo niewielu wierszy kodu w konstruktorze. Weźmy na przykład najprostszy przykład - dodanie połączenia gniazda sygnałowego. Korzystanie z projektanta jest tak proste, jak podwójne kliknięcie. Bez projektanta musisz poszukać poprawnej sygnatury sygnału, edytować plik .h, a następnie edytować i zapisać kod w pliku .cpp. Projektant pozwala wznieść się ponad te szczegóły i skupić się na tym, co naprawdę ważne - funkcjonalności Twojej aplikacji.

Lubię najpierw zwrócić się do projektanta, aby opracował widżety GUI. Jak wspomniano w innych postach, jest szybszy. Otrzymujesz również natychmiastową informację zwrotną, aby sprawdzić, czy „wygląda dobrze” i nie jest mylące dla użytkownika. Projektant jest głównym powodem, dla którego wybieram Qt zamiast innych zestawów narzędzi. Najczęściej używam projektanta do tworzenia jednorazowych dialogów.

Powiedziawszy to, ręcznie wykonuję główne okno i wszelkie złożone widżety. Myślę, że tak właśnie zamierzał Trolltech. QFormLayout to klasa, którą zapewniają, aby łatwo programowo tworzyć okno dialogowe wprowadzania danych.

Nawiasem mówiąc, projektant w Qt 4 nie jest IDE takim jak to, które mieli w Qt 3. To tylko edytor do edycji plików .ui. Lubię to w ten sposób. Nowe, wieloplatformowe środowisko IDE będzie się nazywać Qt Creator.

To stary post, ale radziłbym przyjrzeć się Clementine - odtwarzaczowi muzycznemu, który (jak sądzę) wywodzi się z Amaroka. Używają Qt4 iz tego, co widzę, znajduje się folder ui w folderze src projektu. W folderze ui, jak można by się spodziewać, znajdują się różnego rodzaju pliki .ui. Jeśli skompilujesz i uruchomisz Clementine, zobaczysz, że GUI jest dość złożone i całkiem przyjemne.

Dla mnie to zależy od tego, ile logiki jest zawarte w widżecie / GUI. Jeśli chodzi tylko o proste formularze, wolę używać QtDesigner.

Jeśli zawiera złożone kontrole lub interakcje, zwykle go programuję.

Używamy Qt Designer, jeśli ktoś potrzebuje stworzyć Gui.
Chodzi o to, aby stworzyć tylko małe widżety do określonych zadań (tak jak robiłbyś to w projektowaniu klas), a następnie zebrać je razem w "rodzicielskie GUI".

W ten sposób Twoje widżety są wielokrotnego użytku i mogą być używane w Guis w sposób modułowy. Musisz tylko określić, które sygnały wysyła każdy widżet i jakie gniazda zapewniają.

Dodatkowo tworzymy pliki .ui, które mogą być generowane podczas procesu kompilacji. Do tej pory nie było potrzeby ręcznej edycji tych plików.

Zbuduj różne części interfejsu użytkownika
w różnych plikach .ui za pomocą QtDesigner,
a następnie połącz je (i dodaj komplikacje) w kodzie.

Są rzeczy, których nie możesz zrobić w Qt Designer, możesz to zrobić tylko w kodzie,
więc Qt Designer to tylko jedna (świetna) część łańcucha narzędzi .