Czy istnieje trend na wieloplatformowe zestawy narzędzi GUI? [Zamknięte]
12
Jaki jest obecnie trend korzystania z platform międzyplatformowych z graficznym interfejsem użytkownika? Czy więcej osób zaczyna korzystać z platform wieloplatformowych (takich jak GTK +, Qt i wxWidgets), czy też jest więcej osób, które używają więcej platform powiązanych z platformą (np. Cocoa lub WPF)? Czy to jest mniej więcej stagnacja? Czy to jest jak rollercoaster? Jak myślisz, jaki będzie trend, powiedzmy, za 5 lat?
Krajobraz systemu operacyjnego zmienia się, a mniej osób korzysta z systemu Windows (obserwacja osobista). To powinno zwiększyć popyt na wieloplatformowe zestawy narzędzi, prawda?
Edycja: Które (międzyplatformowe) zestawy narzędzi rosną najbardziej, jeśli tak?
Wygląda na to, że istnieje trend przeciwko zestawom międzyplatformowym. Jeśli ludzie chcą napisać raz, uruchomić gdziekolwiek, zwykle używają HTML - stwórz stronę internetową. Ludzie używają zestawów narzędzi platformy tylko wtedy, gdy natywny wygląd jest bardzo wymagany, na przykład na iPhonie. Jeśli więc cały powód, dla którego niepokoisz się aplikacją inną niż internetowa, to mieć natywny wygląd, nie ma sensu używać zestawu wieloplatformowego.
Wieloplatformowe zestawy narzędzi nigdy nie działały tak dobrze; platformy na komputery stacjonarne nie są tak podobne i trudno je naprawdę oddzielić. Dodanie telefonów i tabletów do miksu czyni to jeszcze trudniejszym. W efekcie powstaje bardzo nieszczelna abstrakcja (patrz: http://www.joelonsoftware.com/articles/LeakyAbstractions.html ). Często łatwiej jest po prostu dobrze oddzielić „silnik” od interfejsu użytkownika i napisać interfejs osobno dla każdej platformy.
Trend popularności Maca może sprawić, że zestawy międzyplatformowe będą mniej popularne niż bardziej. Myślę, że często ludzie używali zestawu międzyplatformowego bardziej do teoretycznego zaznaczenia pola wyboru międzyplatformowego niż do uzyskania naprawdę dobrych wyników na wszystkich platformach. Gdy naprawdę zależy Ci na wielu platformach ... zaczynasz widzieć, jak zestawy międzyplatformowe mają swoje wady.
Myślę, że to mówi, że wiele dużych, popularnych aplikacji wieloplatformowych wymyśla własne podejście wieloplatformowe (Firefox, Chrome, Eclipse, OpenOffice.org to przykłady, które przychodzą na myśl). Posiadając strukturę, mogą w razie potrzeby przebijać abstrakcję. Również wszystkie te aplikacje wyglądały tak samo (a nie szczególnie natywnie) na wszystkich platformach.
Wszystko to mówiło: nie mam faktycznych statystyk ani nic takiego. Ale dużo pracy wykonałem na GTK + i znam trochę podstaw kodowych, w tym Firefox, Chrome i Eclipse. Widziałem tutaj wyzwania techniczne z pierwszej ręki.
Wyraziłbym to po prostu jako „Trend międzyplatformowymi zestawami narzędzi zmierza w kierunku niepowodzenia”.
omhmics
14
W rzeczywistości w ostatnich latach pojawiła się tendencja do tworzenia wieloplatformowego zestawu narzędzi. Ten zestaw narzędzi to HTML / CSS / JavaScript.
Raz łatwiej jest go opracować i widziałem, że działa niemal identycznie wszędzie.
I tak, zmiany rozwojowe w znacznym stopniu odchodzą od komputerów stacjonarnych do sieci. Sam to widzisz.
+1 Dla sieci jako rosnącego trendu interfejsu użytkownika, ale myślę, że to nie odpowiada na pytanie OP.
Całkowicie się zgadzam. Rozwijamy naszą aplikację IPTV na urządzeniu Settop w całości przy użyciu HTML5 / CSS3 / JavaScript. To jest przyszłość, a nie kolejna ogromna, w pełni
rozbudowana platforma
1
Dobry wspomnieć, ale jestem naprawdę zainteresowany cross-platform stacjonarnych zestawów narzędzi. Nadal głosowałem.
Anto
@Anto - może chcesz dodać to do swojego pytania. Z lektury wcale nie wychwyciłem „pulpitu”. Oczywiście jestem programistą i nie rozpoznałem większości frameworków, o których wspomniałeś :)
Marcie
@ Na przykład możesz wspomnieć o pulpicie w swoim pytaniu.
JBRWilkinson
7
Zwykle używam zestawów narzędzi między platformami, ponieważ mają lepszy wygląd, a nie dlatego, że staram się być na różnych platformach. Na przykład pracuję nad projektami napisanymi w C ++ przeznaczonymi tylko dla platformy Windows. Czy używam Win32 lub MFC, właściwie TYLKO opcji dostępnych dla natywnego zestawu narzędzi?
Jasna cholera, nie! To właściwie najgorsze kupy śmieci spaghetti, jakie kiedykolwiek widziałem! Bezpośrednie sprzężenie systemu zdarzeń z systemem „komunikatów” systemu operacyjnego jest niezwykle nieintuicyjne i brakuje w nim ekspresji niezbędnej do szybkiego tworzenia programów interfejsu użytkownika. Abstrakty wyższego poziomu, obecnie dostarczane tylko przez wieloplatformowe zestawy narzędzi, są absolutnie niezbędne do zadania.
To tylko jeden przykład. Mógłbym przewijać listę rzeczy, które lepiej zrobić przy użyciu wieloplatformowych zestawów narzędzi. Faktem jest, że interfejsy graficzne są bardziej do siebie podobne niż odrębne. Na przykład niewiele różni się program okienkowy w systemie Windows od jednego w systemie Linux. Rzeczy, które robisz, tworząc programy interfejsu użytkownika, są prawie zawsze takie same, bez względu na system operacyjny, na który celujesz ... i tylko niewielkie różnice między architekturami, takie jak telefon / dłoń w porównaniu z komputerem. Pole po prostu skupiło się na metodologiach między platformami, ponieważ a) jest to konieczne dla wielu osób i b) to wszystko to samo sh! T.
Jednym z argumentów przeciwko tworzeniu frameworkowego frameworka jest to, że zawsze będzie on skierowany na najniższy wspólny mianownik - klienci frameworka chcą napisać kod tylko raz i działa on obsługiwany „wszędzie”. Tak więc jedna niesamowita platforma sprzętowa wyglądałaby jak każda inna platforma działająca w tym frameworku, ponieważ nie można wykorzystać funkcji specyficznych dla platformy.
Z czasem powoduje to, że frameworki skłaniają się ku swojej najpopularniejszej platformie i hakują razem wsparcie dla innych platform lub po prostu odcinają je, gdy skończy się budżet / popularność.
Jednym ze sposobów na wykorzystanie zdolności specyficznych dla platformy jest stworzenie czegoś takiego jak #if PLATFORM_FEATURE_Xkonstrukcja wokół całego określonego kodu lub równoważne kontrole środowiska wykonawczego, co powoduje rozdęcie kodu. Jest to dość nudne, ponieważ warianty tej samej platformy będą wymagały specyficznej obsługi. Na przykład niektóre XBox v1 nie miały dysku twardego, więc gry korzystające z narzędzi wieloplatformowych nie mogły go używać do buforowania, w porównaniu do wersji na PC, w której można zagwarantować dysk twardy.
W przypadku aplikacji Desktop / Productivity wygląd platformy wydaje się ważny, ale wiele aplikacji ma swój własny styl, więc „nie ma problemu, aby wyglądać tak samo na wszystkich platformach, np. Aplikacjach zbudowanych w środowisku AIR.
Dostawcy sprzętu, tacy jak Apple, Sony, Nintendo i Toshiba, będą chcieli upewnić się, że ich produkty robią coś, co wyróżnia się na tle konkurencji, np. Dotyk, akcelerometry / gryoskopy, Blu-Ray, wyświetlacz 3D. Jest mało prawdopodobne, aby kiedykolwiek istniała platforma z wszystkimi funkcjami wszystkich konkurentów połączonymi w jedną (ze względu na koszty i złożoność), więc jedna wygra.
W rzeczywistości w ostatnich latach pojawiła się tendencja do tworzenia wieloplatformowego zestawu narzędzi. Ten zestaw narzędzi to HTML / CSS / JavaScript.
Raz łatwiej jest go opracować i widziałem, że działa niemal identycznie wszędzie.
I tak, zmiany rozwojowe w znacznym stopniu odchodzą od komputerów stacjonarnych do sieci. Sam to widzisz.
źródło
Zwykle używam zestawów narzędzi między platformami, ponieważ mają lepszy wygląd, a nie dlatego, że staram się być na różnych platformach. Na przykład pracuję nad projektami napisanymi w C ++ przeznaczonymi tylko dla platformy Windows. Czy używam Win32 lub MFC, właściwie TYLKO opcji dostępnych dla natywnego zestawu narzędzi?
Jasna cholera, nie! To właściwie najgorsze kupy śmieci spaghetti, jakie kiedykolwiek widziałem! Bezpośrednie sprzężenie systemu zdarzeń z systemem „komunikatów” systemu operacyjnego jest niezwykle nieintuicyjne i brakuje w nim ekspresji niezbędnej do szybkiego tworzenia programów interfejsu użytkownika. Abstrakty wyższego poziomu, obecnie dostarczane tylko przez wieloplatformowe zestawy narzędzi, są absolutnie niezbędne do zadania.
To tylko jeden przykład. Mógłbym przewijać listę rzeczy, które lepiej zrobić przy użyciu wieloplatformowych zestawów narzędzi. Faktem jest, że interfejsy graficzne są bardziej do siebie podobne niż odrębne. Na przykład niewiele różni się program okienkowy w systemie Windows od jednego w systemie Linux. Rzeczy, które robisz, tworząc programy interfejsu użytkownika, są prawie zawsze takie same, bez względu na system operacyjny, na który celujesz ... i tylko niewielkie różnice między architekturami, takie jak telefon / dłoń w porównaniu z komputerem. Pole po prostu skupiło się na metodologiach między platformami, ponieważ a) jest to konieczne dla wielu osób i b) to wszystko to samo sh! T.
źródło
Jednym z argumentów przeciwko tworzeniu frameworkowego frameworka jest to, że zawsze będzie on skierowany na najniższy wspólny mianownik - klienci frameworka chcą napisać kod tylko raz i działa on obsługiwany „wszędzie”. Tak więc jedna niesamowita platforma sprzętowa wyglądałaby jak każda inna platforma działająca w tym frameworku, ponieważ nie można wykorzystać funkcji specyficznych dla platformy.
Z czasem powoduje to, że frameworki skłaniają się ku swojej najpopularniejszej platformie i hakują razem wsparcie dla innych platform lub po prostu odcinają je, gdy skończy się budżet / popularność.
Jednym ze sposobów na wykorzystanie zdolności specyficznych dla platformy jest stworzenie czegoś takiego jak
#if PLATFORM_FEATURE_Xkonstrukcja wokół całego określonego kodu lub równoważne kontrole środowiska wykonawczego, co powoduje rozdęcie kodu. Jest to dość nudne, ponieważ warianty tej samej platformy będą wymagały specyficznej obsługi. Na przykład niektóre XBox v1 nie miały dysku twardego, więc gry korzystające z narzędzi wieloplatformowych nie mogły go używać do buforowania, w porównaniu do wersji na PC, w której można zagwarantować dysk twardy.W przypadku aplikacji Desktop / Productivity wygląd platformy wydaje się ważny, ale wiele aplikacji ma swój własny styl, więc „nie ma problemu, aby wyglądać tak samo na wszystkich platformach, np. Aplikacjach zbudowanych w środowisku AIR.
Dostawcy sprzętu, tacy jak Apple, Sony, Nintendo i Toshiba, będą chcieli upewnić się, że ich produkty robią coś, co wyróżnia się na tle konkurencji, np. Dotyk, akcelerometry / gryoskopy, Blu-Ray, wyświetlacz 3D. Jest mało prawdopodobne, aby kiedykolwiek istniała platforma z wszystkimi funkcjami wszystkich konkurentów połączonymi w jedną (ze względu na koszty i złożoność), więc jedna wygra.
źródło