Dlaczego trudno jest sprawić, by program Java „pojawiał się”?

98

Większość aplikacji Java nie wygląda tak samo jak aplikacje C / C ++. Swing mógł zostać zaprojektowany specjalnie, aby mieć wyjątkowy wygląd, ale na podstawie tego, co przeczytałem, SWT na przykład próbował „wyglądać na rodzimego” i nie do końca się udaje.

Moje pytanie brzmi:

Dlaczego twórcom języka Java trudno jest zaprojektować system GUI, który dokładnie kopiuje wygląd natywnych GUI? Czym różnią się natywne interfejsy GUI? Czy nie chodzi tylko o zaprojektowanie przycisków, które wyglądają jak przyciski „rodzime”? Czy może idzie to głębiej?

użytkownik3150201
źródło
31
ponieważ swing pisze własne komponenty GUI, które próbują naśladować elementy natywne, zamiast tworzyć powiązanie z rzeczywistymi elementami natywnymi, zgodnie z ideą przenośności
maniak ratchet
5
Nie jestem ekspertem w tym temacie, ale wydaje mi się, że jest to tylko kwestia wysiłku, jaki dostawcy narzędzi GUI są gotowi zainwestować, aby uzyskać odpowiednie krwawe szczegóły. Zobacz na przykład ramkę C ++ „Qt” i to pytanie SO: stackoverflow.com/questions/7298441/...
Doc Brown
4
Jest wiele szczegółów do załatwienia. Na przykład sposób automatycznego uzupełniania w otwartym oknie dialogowym pliku to jeden punkt, w którym zepsuła się natywna aplikacja Java.
CodesInChaos
4
Swing ma wygląd „natywny”, który można podłączyć zamiast domyślnego. Ponadto Java najpierw próbowała użyć dostępnych natywnych rzeczy z AWT, ale nie działało to zbyt dobrze, AFAIK z powodu nieodłącznych różnic między platformami. Właśnie dlatego stworzyli Swing, aby aplikacja Java działała dokładnie tak samo wszędzie.
marczellm
5
Nie przegap JavaFX. Jest to zamiennik SWING i domyślnie znajduje się w JDK / JRE, począwszy od Java 8. Jest znacznie nowocześniejszy niż SWING i AWT i wygląda na znacznie bardziej natywny na prawie wszystkich platformach (bardzo przyczepia się do natywnego zestawu narzędzi interfejsu użytkownika na każdej z nich Platforma). Biorąc to pod uwagę, jak wspomniano inni, aby uzyskać dokładnie natywną aplikację z języka „jednego rozmiaru dla wszystkich”, takiego jak Java, będziesz musiał wykonać trochę pracy. Interfejsy użytkownika Java były / były / są nadal przeznaczone do „najlepszego dopasowania na wszystkie platformy” od razu po wyjęciu z pudełka.
SnakeDoc

Odpowiedzi:

56

Czy nie chodzi tylko o zaprojektowanie przycisków, które wyglądają jak przyciski „rodzime”?

Cóż - coś w rodzaju przycisków. Ale może to być trudniejsze niż można sobie wyobrazić. Obecnie grafika używana do reprezentowania komponentów GUI nie jest tak prosta jak losowe bitmapy, które są rozciągane (ponieważ wcale nie są zbyt dobrze skalowane) - często są to grafiki wektorowe z zaprogramowanymi wieloma przypadkami narożnymi ( więc kiedy przycisk osiągnie krawędź ekranu, może na przykład wyglądać nieco inaczej.) I oczywiście, będziesz potrzebować innej grafiki po kliknięciu przycisku. Z powodów związanych z prawami autorskimi programiści często nie mogą po prostu użyć tej istniejącej grafiki, więc trzeba je odtworzyć - i chociaż wykonują dobrą robotę w przeważającej części, nieuchronnie pewne rzeczy są pomijane, biorąc pod uwagę ogromną gamę komponentów graficznych.

Mówię wszystko powyższe w oparciu o Swing, który jest oczywiście lekkim, nienatywnym zestawem GUI. W szczególności wspominasz, że SWT nie wygląda na natywny, co jest nieco dziwne, ponieważ SWT jest natywny. Jest to zestaw narzędzi, który używa JNI pod spodem do wywoływania komponentów natywnych - więc jeśli coś tam nie wygląda, to nie będzie tak z powodu wyglądu.

berry120
źródło
1
Dzięki. Co dokładnie oznacza „lekki”? A co właściwie oznacza „rodzimy”? Zakładam, że oznacza to coś, co wykorzystuje zasoby z systemu operacyjnego komputera lub bezpośrednio z nim współdziała. Czy to prawda?
user3150201
1
@ user3150201 Jasne, więc podstawowy system operacyjny będzie miał ustaloną liczbę przycisków i widżetów, które można umieścić natywnie, ale oczywiście przyciski te będą się różnić między systemami operacyjnymi i platformami - są to ciężkie, natywne komponenty. Lekkie komponenty nie są komponentami podyktowanymi przez system operacyjny, są rysowane przez Javę (w tym przypadku), aby wyglądały i zachowywały się jak komponenty GUI - dzięki czemu mogą wyglądać tak, jak chcesz, jeśli włożysz pracę (ale musisz emulować platforma wygląda i czuje, jeśli tego chcesz, nie dostajesz jej za darmo.)
berry120
14
Rozmieszczenie przycisków, dokładne rozmiary i preferowane style GUI różnią się w zależności od platformy, a naśladowanie ich przez Javę wymaga pracy. Swing może dać ci natywny przycisk, ale jeśli ma 10 pikseli wysokości, użytkownik nadal będzie myślał, że coś jest nie tak. Apple ma wytyczne dotyczące interfejsu użytkownika, a Microsoft ma wytyczne dotyczące interfejsu użytkownika, które pomagają uzyskać prawidłowy wygląd natywny. Musisz nieco zmienić interfejs użytkownika między platformami.
Michael Shopsin
4
JavaFX wydaje się znacznie bardziej „natywny” niż SWING i AWT. Ma natywne przezroczyste okna itp. Znacznie nowocześniejszy wygląd po wyjęciu z pudełka.
SnakeDoc
2
@SnakeDoc Wygląda na to, że jest bardziej nowoczesny, ale nie powiedziałbym, że wydaje się „natywny” - z pewnością nie korzysta z podstawowych komponentów GUI platformy, wszystkie są skórowane w CSS.
berry120
71

Istnieje dosłownie pół tuzina zestawów narzędzi, które można by uznać za „natywne” w niektórych systemach. Niektóre z nich mają raczej unikalne koncepcje lub możliwości, a ich replikacja w wieloplatformowym zestawie narzędzi jest żmudna. Wygląd aplikacji zależy nie tylko od „skóry”, ale również od układu i sposobu jej działania. Niektóre uwagi:

  • Po której stronie należy w oknie dialogowym przycisk „OK” - po lewej czy po prawej stronie? W porządku, stwórzmy osobne okno dialogowe dla każdego systemu.
  • Jak oznaczyć domyślny przycisk na ekranie? Barwienie, pogrubiona czcionka, powiększanie przycisku? W porządku, umieśćmy to w arkuszu stylów.
  • W systemie Windows koncepcja „Wstążki” jest raczej natywna. Jak można to przetłumaczyć na Maca, gdzie Wstążka nie jest powszechna? Uczciwie, zapomnijmy o układzie z dokładnością do pikseli i zapewnij inną implementację paska narzędzi dla każdego systemu.
  • Czy pasek menu jest częścią okna (Windows, opcjonalnie KDE), czy też znajduje się u góry ekranu (Mac, Unity)? W porządku, napiszmy inną implementację dla każdego systemu, ponieważ już wyrzuciliśmy układ dokładnie w pikselach
  • Jak renderowane są czcionki? Jak najostrzejszy, czy gładki i wygładzony? I jakiej czcionki należy użyć? Pamiętaj, że różne czcionki mają różne parametry, więc ten sam akapit renderowany na tę samą szerokość może mieć różną liczbę linii w zależności od czcionki.
  • Czy tło okna jest jednym kolorem, obrazem lub gradientem? Umieśćmy to również w arkuszu stylów.
  • Jak wyglądają paski przewijania? Gdzie są przyciski - jeśli mają? Jak szerokie są lub czy ujawniają się dopiero, gdy wskaźnik przesunie się do określonego regionu?
  • Jak wprowadzamy inne schematy kolorów?
  • Czego można się przeciągać? Gdzie są oczekiwane menu kontekstowe?

Tych problemów nie można rozwiązać za pomocą prostego arkusza stylów, gdy dotyczą zachowania lub ogólnego układu aplikacji. Jedynym prawdziwym rozwiązaniem jest ponowne napisanie aplikacji dla każdego systemu (ignorując w ten sposób korzyści płynące z platformy Java dla wielu platform). Jedynym realistycznym rozwiązaniem jest zapomnienie o układzie z dokładnością do pikseli i napisanie do wspólnego interfejsu, który jest abstrakcyjny w stosunku do zestawów narzędzi specyficznych dla systemu. Rozwiązaniem zastosowanym przez Swing jest emulacja różnych systemów, co zawodzi spektakularnie.

A potem jest spójność między platformami, pomysł, że Twoja aplikacja może wyglądać dokładnie tak samo na wszystkich systemach (często wybieranych przez gry, w których zwiększa to zanurzenie). W przypadku aplikacji komputerowych jest to po prostu denerwujące i łamie oczekiwania użytkowników.

amon
źródło
1
+1. Chciałbym tylko dodać jedną rzecz: co z tym, co system pozwala użytkownikowi skonfigurować, zaczynając od „prostych” szczegółów, takich jak otwieranie menu kontekstowych? (I wolałbym, żeby programy Windows miały wstążki i aplikacje na Maca, nie, dziękuję. Tak, dobre GUI muszą być zaprojektowane dla systemu operacyjnego.)
Christopher Creutzig
@ChristopherCreutzig Stąd moje doświadczenie: na moim głównym pulpicie używam KDE w Linuksie (oba są bardzo konfigurowalne) i używam QtCurve do dostosowania wyglądu aplikacji. Te specjalne style działają dobrze w flagowych aplikacjach KDE. Dobrze napisane aplikacje GTK mogą korzystać z warstwy kompatybilności, ale brakuje gradientów tła, pasek menu pozostaje w oknie itp. Ale potem szybko zaczyna się pogarszać, a programy pobierają niektóre widżety ze stylu systemu (np. Paski przewijania) , ale ignorowanie innych (np. renderowanie czcionek lub cienie wokół menu)
amon
+1, ponieważ w tej odpowiedzi są pewne mocne strony, ale są też słabe punkty. Każdy problem „w jaki sposób ten menedżer okien rysuje X” jest obsługiwany przy użyciu natywnego interfejsu API. Na przykład X11 w systemie OS X może rysować natywne okna systemu OS X, przyciski, paski przewijania, okna dialogowe itp. Tak więc wiele z tych problemów znika. Prawdziwa odpowiedź jest to, co powiedział @TheSpooniest poniżej: UX jest tak dużo więcej niż tylko widgetów rysunkowych. Odstępy, czas, animacja, przyspieszenie myszy, wprowadzanie dotykowe ... istnieje świat subtelnych szczegółów, których odtworzenie za pomocą wieloplatformowego zestawu narzędzi jest bardzo kosztowne.
Mark E. Haase,
13

Tak, idzie głębiej.

Zbudowanie przycisku, który wygląda jak przycisk systemu Windows lub OS X, jest łatwe, jeśli budujesz tylko ten przycisk. Ale przycisk musi „zachowywać się” jak oryginalne, co może nie być łatwe: może w jednej wersji jest więcej miejsca, ale nie w drugiej, może kolor bardziej pasuje do twojego projektu w wersji Windows itp.

Jest to rozgałęzione, gdy masz cały GUI: program OS X prezentuje swoją zawartość inaczej niż program Windows. Jest to prawie niemożliwe do uchwycenia w jednym GUI - potrzebujesz dwóch GUI, ale niewiele aplikacji sprawia tyle problemów. Zamiast tego dążą do „wygląda dobrze na większości systemów” - nadal wygląda to trochę obco, ale jest użyteczne i znacznie łatwiejsze do opracowania.

Christian Sauer
źródło
9

Nie jest trudno stworzyć przycisk, który wygląda jak przycisk OSX, Windows lub jakikolwiek inny zestaw narzędzi. Jednak wytyczne interfejsu użytkownika dla większości środowisk nie są tak proste, jak podstawy „tak wygląda przycisk”. Istnieje wiele subtelniejszych różnic, od odstępów między elementami interfejsu użytkownika do kolejności, w której pewne dobrze znane akcje powinny pojawić się na liście, do dokładnej pozycji okna dialogowego Preferencje / Opcje w systemie menu. Można zautomatyzować najczęstsze przypadki dla bardzo prostych interfejsów użytkownika, ale wiele, jeśli nie większość zadań interfejsu użytkownika wymaga znacznie lepszego dotyku.

SWT próbowało do pewnego stopnia zautomatyzować to i po raz kolejny robi to dobrze dla prostych zadań interfejsu użytkownika. Ale nie ma jednego uniwersalnego rozwiązania, więc kiedy interfejsy użytkownika stają się bardziej złożone, podstawowe metody, których używa, zaczynają się rozpadać. Zasadniczo możliwe jest dostosowanie go do żmudnej ręcznej pracy interfejsu użytkownika, ale nie jest to coś, co większość programistów jest w stanie lub jest skłonna zrobić dla wszystkich platform.

Podejście Swinga polegało na unikaniu natywnych zestawów narzędzi, gdy tylko było to możliwe. Nie jest natywny i nie próbuje: zamiast tego próbuje stworzyć coś, co będzie wyglądało (prawie) tak samo, bez względu na to, gdzie zostanie uruchomione. Zamiast próbować (bezskutecznie) zadowolić wszystkich, starał się zadowolić siebie i chociaż udało mu się to w tym zakresie, można kwestionować skuteczność tego działania dla szerszej społeczności użytkowników.

The Spooniest
źródło
7

Istnieje kompromis między oczekiwaniem, że aplikacja będzie wyglądać tak naturalnie, jak to możliwe na każdym systemie, a oczekiwaniem, że aplikacja będzie działać w ten sam sposób na każdym systemie. Nie ma „właściwego” wyboru.

Co więcej, nawet jeśli wybierzesz „naturalnie wyglądającą” stronę, możesz chcieć chronić użytkowników twojego graficznego zestawu narzędzi przed „ulepszeniami” w podstawowych komponentach natywnych i API, które mogą nieoczekiwanie zepsuć ich aplikację.

To dlatego niektórzy programiści GUI wolą dostarczać własne komponenty, które naśladują natywne, ale zapewniają własną implementację. Z drugiej strony opracowanie funkcjonalnie kompletnego zestawu narzędzi GUI to znaczny wysiłek, a względy ekonomiczne mogą prowadzić do ograniczenia kilku aspektów.

Pamiętaj, że ten problem nie jest związany z Javą, ale napotyka go każda firma produkująca niezależne od platformy zestawy narzędzi.

Nicola Musatti
źródło
Zamiast dyskretnie oddać głos, zrobiłbyś większą przysługę dla społeczności, wyjaśniając, co uważasz za błędne w odpowiedzi. Chyba że to tylko kwestia osobista ...
Nicola Musatti
4

Wszystko dzięki historii.

Firma Sun chciała, aby całe oprogramowanie Java działało tak samo na wszystkich komputerach.

Aby oprogramowanie „wyglądało na natywne”, musi działać tak samo, jak inne oprogramowanie w danym systemie operacyjnym.

Firma Sun zrobiła wszystko, co w ich mocy, aby utrudnić pisanie oprogramowania Java zintegrowanego z systemem operacyjnym, ponieważ każda integracja z systemem operacyjnym sprawiłaby, że oprogramowanie działałoby inaczej w każdym systemie operacyjnym.

Obecnie niewielu programistów Java interesuje się czymkolwiek innym niż oprogramowanie oparte na serwerze WWW.

Sun zabił Javę na pulpicie, przetrząsając wszystkich programistów, którzy korzystali z systemów opartych na Javie Microsoft, przez co każdy programista, który wybrał Javę na początku, wyglądał źle.

Każdy, kto pisze oprogramowanie komputerowe, które dba o „wygląd natywny”, nauczył się dawno temu, że nie korzysta z Javy, a jego poglądy są wzmacniane za każdym razem, gdy używają oprogramowania Oracle.

Dlatego w dzisiejszych czasach nie ma zapotrzebowania na „pojawienie się” w oprogramowaniu komputerowym od programistów Java.

Ian
źródło
5
„Firma Sun zrobiła wszystko, co w ich mocy, aby utrudnić pisanie oprogramowania Java zintegrowanego z systemem operacyjnym”, źle. Po prostu nie wkładają wielkiego wysiłku, aby to ułatwić. „Sun zabił Javę na pulpicie, wprowadzając w błąd wszystkich programistów, którzy używali systemów opartych na Javie Java”, wzajemna wrogość między Microsoftem i Sunem spowodowała, że ​​Microsoft stworzył wersję bibliotek AWT, która nie była zgodna z wymaganiami Sun, powodując złą sławę Pozwy Sun / MS.
jwenting
1
@jwenting, Sun bardziej zależało na tworzeniu problemów dla Microsoftu niż na programistach, którzy wybrali system Microsoft oparty na Javie. Stąd ja zrezygnował Jave i przechowywane w MFC C #, aż wyjdzie.
Ian
3
może niektórzy ludzie w Sun, ale ten sentyment był wzajemny. Jeśli tworzysz wyłącznie dla jednej platformy, natywnym narzędziem dla tej platformy ZAWSZE jest preferowana opcja, nie ma to nic wspólnego z polityką korporacyjną. Jeśli wybierzesz swoje narzędzia w oparciu o „Nienawidzę Sun” lub „Nienawidzę Microsoft”, to bardzo źle odbija się na Twoim profesjonalnym nastawieniu. Najczęściej używałem Javy, ale oprócz tego używałem także Delphi, C #, Ruby, C ++, C, Progress, wszystkiego, co było najlepsze dla danego zadania. I najczęściej będzie to rozwiązanie hybrydowe.
jwenting
3

To, co uważasz za nativerzeczywiste, to aplikacje natywne, które robią swoje, a zestawy narzędzi takie jak SWT są zgodne z opublikowanymi standardami interfejsu użytkownika tego systemu operacyjnego. Problem polega na tym, że nikt nie tworzy aplikacji zgodnych z tymi standardami, więc po uruchomieniu aplikacji Java. Wygląda na to, że nie jest natywny. Na przykład prawie wszystkich projektów Microsoft (Office, Outlook itp.) Nie można odtworzyć wizualnie przy użyciu standardowych kontrolek Windows.

Będzie jeszcze gorzej, gdy zarówno Microsoft, jak i Apple dodadzą dynamiczne funkcje interfejsu użytkownika do swoich platform operacyjnych. Umożliwianie programistom zmiany wyglądu i stylizacji aplikacji w ten sam sposób, w jaki projekty internetowe tworzą style dla stron internetowych.

Java na platformie Android podąża tą ścieżką. Tworzenie elementów interfejsu użytkownika dla systemu Android zdefiniowanych w języku XML za pomocą stylów z możliwością zmiany skórki.

Java nigdy nie była tak popularna jako platforma komputerowa. W rezultacie te zmiany w branży nie rozprzestrzeniają się do środowisk uruchomieniowych komputerów stacjonarnych. Po prostu nie ma wystarczającej liczby programistów gotowych poświęcić czas na rozwiązanie problemu.

Reactgular
źródło
1
+1, w erze Windows 95 pojawił się „standardowy” wygląd kontrolek Windows. Teraz nie tak bardzo.
GrandmasterB
Tak, minęło kilka lat, odkąd zaprogramowałem komputer stacjonarny, ale byłem zaskoczony, że .NET nie został dostarczony ze sterowaniem w stylu wstążki, mimo że stał się integralną częścią oprogramowania produkcyjnego MS.
Przypon
@Rig Od wersji NET 4.0 istnieje dobra natywna kontrola wstążki w .NET. Oto dobry artykuł: c-sharpcorner.com/UploadFile/0b73e1/ribbon-control-in-wpf-4-5
Christian Sauer
1
@Rig Będziesz potrzebować .NET 4.5, a nie .NET 4. Visual Studio 2010 może kierować tylko do 4; będziesz potrzebować VS2012 lub nowszego, aby kierować na 4.5. Widzę to, gdy celuję w 4.5 w VS2013, ale nie kiedy zmieniam wersję docelową na 4.
Bob
1
@Rig Można użyć Wstążki w Net 4.0 - możesz pobrać ją z Microsoft, a następnie pojawi się: 10rem.net/blog/2010/10/22/wpf-ribbon-october-release (Nie jestem pewien, czy to to najnowsza wersja). Lepiej pobierz go z Nuget. Musiałem to zrobić dla programu, który musiał działać na Windows XP - działa dobrze i jest w większości kompatybilny z wariantem Net 4.5, więc możesz wyrwać 4.0 z rzeczy, gdy XP w końcu przejdzie na emeryturę.
Christian Sauer
-1

Który system operacyjny też chcesz wyglądać na „natywny”?

Po prostu nie możesz być dla nich wszystkich przez 100% czasu.

SWT itp. Są najlepszym podejściem, aby wyglądać tak natywnie dla nich wszystkich, jak to możliwe, gdy trzeba osiągnąć kompromis .

W rzeczywistości kompromis ten staje się coraz trudniejszy do osiągnięcia; nie tyle z powodu systemów operacyjnych, ale z powodu urządzeń wejściowych. W przypadku ekranów dotykowych trzeba projektować inaczej, ponieważ nie ma prawego przycisku myszy. Dlatego w przeciwnym razie musisz dostosować tę samą funkcjonalność.

Nigdy nie będzie magiczny przycisk, który przenosi funkcjonalność „intuicyjnie” z prawego przycisku myszy guestures, bez wy specifiying każdy szczegółowy aspekt dla każdego urządzenia wejściowego (w tym momencie, jesteś native do każdej platformy zostały uznane, ale mimo to nie - dotyczy każdego, którego nie wziąłeś pod uwagę).

Anony-Mus
źródło
-2

Naprawdę dobre pytanie. Zawsze zastanawiałem się nad tym przez kilka następnych lat w przeszłości, myślałem, że jest jakiś uzasadniony powód, ale tak naprawdę nie ma.

Myślę, że odpowiedź jest raczej prosta i wiele odpowiedzi tak naprawdę nie zagłębia się w problem.

Jeśli Twój język pozwala narysować piexel na ekranie, możliwe jest w 100% stworzenie na nim frameworka GUI, który będzie naśladował wygląd i działanie formantów systemu Windows.

Ponieważ Java jest wieloplatformowa, można również całkowicie upewnić się, że w oparciu o rzeczywisty typ systemu operacyjnego (Mac / Windows) interfejs użytkownika będzie wyglądał inaczej na obu platformach, pasując do stylu platformy wykonawczej.

Jak widać w XAML, na przykład interfejs użytkownika można łatwo przedstawić w bardzo uporządkowanej formie i języku. Wybór zachowań „rodzimych” jest również możliwy, jeśli zajmie to trochę czasu.

Możliwe byłoby więc stworzenie frameworka GUI, który pozwoliłby programistom Java uzyskać aplikacje, które wyglądałyby natywnie na komputerach Mac i Windows.

Dochodzimy do Swinga, czyli tylko jednego frameworku GUI z potencjalnej nieskończoności frameworku GUI, które można stworzyć dla Javy. Zachowuje się tak, jak został zaprogramowany, co nie jest zgodne z powyższym procesem, a aplikacje w obu systemach są dziwnie wyglądające. Taki wybór dokonali twórcy Swinga, nikt nie zmusił ich do zrobienia tego i zachowania w ten sposób.

Valentin Kuzub
źródło
2
to nie odpowiada na pytanie, pytający już omówił ten punkt: „Huśtawka mogła zostać zaprojektowana specjalnie, aby mieć charakterystyczny wygląd”
komara
Nie zgadzam się, ale dziękuję za skomentowanie twojego minusa (?)
Valentin Kuzub