Autor Wątek: WPF kontra środowiska multiplatformowe GUI na przykładzie banalnej aplikacji  (Przeczytany 2880 razy)

therealremi

  • Gość
# Marzec 12, 2010, 09:44:36
W kilka godzin napisałem w WPF przykładową aplikację - powiedzmy, że służy ona do prymitywnej nauki języka: u góry ListBox wyświetla zwroty (pytania), a po kliknięciu któregoś poniżej otrzymujemy wersję w języku, którego się uczymy (odpowiedź). Dane, które możemy edytować, automatycznie serializowane są do pliku XML. Nie ma jakiegokolwiek laga przy przewijaniu ListBoxa zawierającego ponad 1000 stringów.

http://dl.dropbox.com/u/2659857/LangTest.exe
Kod C#, który musiałem wklepać, to 6,85KB, reszta to XAML opisujący kontrolki.

Pytanie: załóżmy, że chciałbym to napisać w jakimś środowisku multiplatformowym, tak żeby wynikowy exec uruchamiał się na Windzie i na Linuxie (powiedzmy 5 pierwszych dystrybucji z distrowatch.com) bez instalowania jakichkolwiek bibliotek - wszystko co potrzebne powinno być linkowane statycznie. Wspierany język nie gra roli. Ktoś jest to w stanie napisać w środowisku X tak, żeby ilość kodu była porównywalna z tą z WPF (im mniej tym lepiej) i żeby list box nie lagował?

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline counterClockWise

  • Użytkownik

# Marzec 12, 2010, 09:54:14
roli. Ktoś jest to w stanie napisać w środowisku X tak, żeby ilość kodu była porównywalna z tą z WPF (im mniej tym lepiej) i żeby list box nie lagował?

Co to jest środowisko X? Pytam poważnie, bo wszystko da się zrobić niskopoziowo i na pewno nie będzie wolniej niż WPF, tylko dużo roboty :)

therealremi

  • Gość
# Marzec 12, 2010, 10:14:20
Co to jest środowisko X? Pytam poważnie, bo wszystko da się zrobić niskopoziowo i na pewno nie będzie wolniej niż WPF, tylko dużo roboty :)
No właśnie chciałbym, żeby ktoś tu podstawił coś za X. Bo ja również jak najbardziej poważnie jestem zainteresowany żeby pisać w X tak szybko, z taką wygodą i tak wysokopoziomowo jak w WPF. Oczywiście X musi nie mieć podstawowej wady WPF - nieprzenośności (Mono, nie dość że nie jest w domyślnych instalacjach linuxów, to nie wspiera i nie ma zamiaru wspierać WPF).

Offline owyn

  • Użytkownik

# Marzec 12, 2010, 10:47:12
Ja bym stawił na Javę. Wadą jest to, że trzeba zainstalować JVM, ale zazwyczaj jest już dołączany standardowo do systemu lub można ją prosto doinstalować.

Offline counterClockWise

  • Użytkownik

# Marzec 12, 2010, 11:25:38
Ja bym stawił na Javę. Wadą jest to, że trzeba zainstalować JVM, ale zazwyczaj jest już dołączany standardowo do systemu lub można ją prosto doinstalować.

Java + GUI + wydajność trochę się dla mnie kłóci. Większość programów z typowo javovym GUI - typu Poseidon UML działa wolno.

Offline Liosan

  • Redaktor

# Marzec 12, 2010, 11:30:11
Ej, no bez przesady - jeśli kryterium wydajności jest "wyświetlanie 1000 stringów w listboxie bez laga", to myślę że Java wyrobi :)

Liosan

Offline counterClockWise

  • Użytkownik

# Marzec 12, 2010, 11:34:07
Ej, no bez przesady - jeśli kryterium wydajności jest "wyświetlanie 1000 stringów w listboxie bez laga", to myślę że Java wyrobi :)

Liosan

No w sumie tak, ale bajerów bym nie oczekiwał :)

therealremi

  • Gość
# Marzec 12, 2010, 14:40:48
To, że "się da" w Javie to się domyślam. Chodzi mi o najlepszy substytut WPF.
Podstawowe pytanie: czy Javowy program uruchomi się bez problemów na standardowej instalacji podanych wyżej platform? Głowa mnie już boli od tych wszystkich JVM, JRE, JDK etc., w kilku implementacjach, przy czym domyślam się, że implementacja Suna nie jest dołączana domyślnie do najważniejszych linuxów z powodów licencji, a te które są dołączane nie są w 100% kompatybilne ze standardem?
Drugie pytanie: jak nazywa się technologia do pisania UI w Javie? Bo C# to nie WPF. Przypuszczam, że tworzenie UI w tej technologi filozofią przypomina Windows Forms?
Trzecie pytanie: jak dużo kodu UI klepie się ręcznie w porównaniu z takim WPF? Przykładowo w powyższej aplikacji mam coś takiego:
    [System.Serializable]
    public class Item
    {
        private string question;
        private string answer;
        /.../
    }

    [System.Serializable]
    public class Items : System.Collections.ObjectModel.ObservableCollection<Item>
    {
     /.../
    }

    public partial class Window1 : System.Windows.Window
    {
        private Items the_items;

        public Window1()
        {
            InitializeComponent();

            the_items = Items.create(file);
            questions.ItemsSource = the_items;
        }
        /.../
     }
i automatycznie dostaje serializacje oraz update listboxa przy zmianie śledzonej kolekcji.
« Ostatnia zmiana: Marzec 12, 2010, 14:49:21 wysłana przez POLAK »

Offline Dab

  • Redaktor
    • blog

# Marzec 12, 2010, 14:51:30
Może C++, OpenGL i jakaś biblioteka do GUI? Będzie przenośnie, wydajnie, ale pewnie o wiele mniej zautomatyzowane niż WPF. Ale wszystkie 3 naraz to tylko w Erze. :)

Offline Kos

  • Użytkownik
    • kos.gd

# Marzec 12, 2010, 14:55:19
Może C++, OpenGL i jakaś biblioteka do GUI? Będzie przenośnie, wydajnie, ale pewnie o wiele mniej zautomatyzowane niż WPF. Ale wszystkie 3 naraz to tylko w Erze. :)

Ale po co sierpem, skoro są kombajny? Aż tak bardzo szkoda Ci tej odrobiny benzyny? :)

Offline Dab

  • Redaktor
    • blog

# Marzec 12, 2010, 15:05:55
No cóż, jeżeli odpada .NET i Java to zostaje nam w zasadzie GTK+ albo Qt. Jeden i drugi głównie zwiększy EXEka do niebotycznych rozmiarów, linkowany statycznie. W automatyzacji GTK+ wiele nie pomoże, nie wiem jak Qt. A OpenGL zawsze jakiś będzie w systemie, nawet jeżeli emulowany przez DX czy MESę. :)

Offline bies

  • Użytkownik

# Marzec 12, 2010, 15:14:29
Gtk+ oraz Qt (bez licencji komercyjnej) i linkowanie statyczne to śliska sprawa (ale jeszcze nie ma decyzji sądu czy można). Tylko, prawdę powiedziawszy, nie rozumiem potrzeby linkowania statycznego.

therealremi

  • Gość
# Marzec 12, 2010, 16:31:18
Tylko, prawdę powiedziawszy, nie rozumiem potrzeby linkowania statycznego.
Wygoda użytkownika końcowego? Nie musi on doinstalowywać jakiś bibliotek o których nie ma on zielonego pojęcia. Podam mu nazwę do wpisania w menedżerze pakietów to w takiej Mandrivie wyskoczy mu kilka różnych wersji. Podam linka to wcześniej czy później on wygaśnie. Przynajmniej ja bym nie zakładał, że user znajdzie w sobie cierpliwość żeby coś zmieniać w systemie pod moją aplikację.
Dystrybuowanie bibliotek wraz z aplikacją też jest trochę naciągane jeśli sama aplikacja to ułamek ich rozmiaru.
W końcu - im mniej plików aplikacji i mniej zewnętrznych zależności tym mniejsza szansa, że user coś zepsuje.

Offline bies

  • Użytkownik

# Marzec 12, 2010, 16:38:58
Tylko, prawdę powiedziawszy, nie rozumiem potrzeby linkowania statycznego.
Wygoda użytkownika końcowego? Nie musi on doinstalowywać jakiś bibliotek o których nie ma on zielonego pojęcia. (...) Dystrybuowanie bibliotek wraz z aplikacją też jest trochę naciągane jeśli sama aplikacja to ułamek ich rozmiaru. (...)
Masz do wyboru albo dołączyć so i ustawić LD_LIBRARY_PATH albo bawić się z bibliotekami statycznymi (powodzenia).

// edit
Możesz też robić pakiety pod konkretne wersje dystrybucji -- a mi by się nie chciało (jeśli mam zrobić dla czegoś więcej niż PLD i konkretna wersja RHEL).
« Ostatnia zmiana: Marzec 12, 2010, 16:40:45 wysłana przez bies »

Offline jupi999

  • Użytkownik

# Marzec 12, 2010, 18:42:40
Cytuj
Java + GUI + wydajność trochę się dla mnie kłóci. Większość programów z typowo javovym GUI - typu Poseidon UML działa wolno.
A JavaFX też jest wolna? Jej wydajność w tworzeniu gui i wszelkich animacji jest dużo większa od typowej Javy, a poza tym java jest zainstalowana na ogromnej ilości komputerów xD więc raczej aplikacja trafi do szerszego grona.