Projekt Seed ma na celu umożliwienie szybkiego pisania programów z GUI w Gtk+. Wykorzystuje silnik WebKit, a w szczególności jego część JavaScriptCore. (Istnieje podobny projekt, GJS oparty na silniku Spidermonkey). Użycie popularnego i dość łatwego w użyciu języka JavaScript ma ułatwić tworzenie prostych programów z użyciem bibliotek Gtk+.

Programy Seed działają jako skrypty uruchamiane przez VM Seed. W pliku skryptu umieszczamy na początku następującą linię:

#!/usr/bin/env seed

lub uruchamiamy poleceniem:

 seed nazwaprogramu.js

Pierwsza odpowiada za wskazanie interpretera, natomiast druga uruchamia program. Poniżej przykłady kodu:

//import biblioteki gtk
Gtk = imports.gi.Gtk;
//inicjowanie Gtk z przekazaniem argumentów
Gtk.init(Seed.argv);
//budujemy okno z pliku Glade
var UI_FILE = "gui.glade";
var builder = new Gtk.Builder();
builder.add_from_file(UI_FILE);
var window = builder.get_object("window");
//dołączamy sygnał zamknięcia aplikacji po zamknięciu okna
window.signal.hide.connect(Gtk.main_quit);
//wyświetlamy okno
window.show_all();
//uruchamiamy główną pętle
Gtk.main();

Dużą zaletą jest możliwość użycia całego WebKita. Można dzięki temu w kilkunastu linijkach kodu zrobić własną przeglądarkę z obsługą JavaScript. Prosty przykład na: people.gnome.org. Więcej przykładów: live.gnome.org/Seed/Tutorial.

Możemy również rozszerzyć możliwości JavaScript przez dodawanie modułów w C.
Można też dodać do swojej aplikacji pisanej w innym języku możliwość pisania wtyczek w JavaScript. Część programów Gnome udostępnia taką możliwość np. Gnome Shell, Nautilius.

Bardzo pozytywną cechą jest podążanie nazw metod obiektów Seed za nazwami bibliotek w C. Przykładowo:

Gio.file_new_for_path("sciezka/do/pliku");

odpowiada bezpośrednio w bibliotece Gio następującej funkcji C:

g_file_new_for_path(char*);

Programiści znający te biblioteki w C, są “w domu”, a nowi będą mogli w razie potrzeby łatwo przejść na C.

Projekt wygląda całkiem ciekawie. Można łatwo tworzyć proste skryty z GUI. Jedynie w większych projektach zapewne lepszym rozwiązaniem jest użycie innego języka, statycznie typowanego i nieco wydajniejszego, na przykład Vala.

Podobne artykuły

  • o_O

    GTK to gówno. Uciekajcie od niego jak najdalej.

    A Qt ma skryptowanie w standardzie plus bindingi do Pythona (PyQt). Polecam.

    > Bardzo pozytywną cechą jest podążanie nazw metod
    > obiektów Seed za nazwami bibliotek w C.

    Chyba negatywną. Gorszego API niż ma GTK w życiu nie widziałem. Widgety, gdzie naturalne są obiekty i klasy, mają gówniane API w C do tego z badziewnym hackiem na brak klas w postaci GObjectu. Po prostu dno i kilometr mułu.

    • Jak sam wspomniałeś, GTK+ jest pisane w C, więc ciężko tu o obiektowość, prawda? Aczkolwiek ja też zdecydowanie wolę QT :)

    • o_O

      Jeśli ktoś wybiera C do czegoś co powinno być obiektowe, a potem sam jeszcze udowadnia swój błąd projektowy tworząc hacki na pseudoobiektowośc w C, to jest po prostu nienormalny. Tacy są właśnie autorzy GTK. I takie samo jest ich dzieło.

    • sprae

      W GUI dobrze sprawdza się też pattern kontekst. Bardzo wygodnie oddziela widok od reszty.

      Robienie wszystkiego osobnymi klasami/obiektami to domena J*** i wynika raczej z optymalizacji (przekazywanie jednej referencji zamiast kilku argumentów na stosie) niźli z wygody.

    • mikolajs

      "Chyba negatywną."
      Właśnie pozytywną, bo nie musisz zmieniając język programowania uczyć się od nowa biblioteki. C++ w Gtkmm to faktycznie ciężki sposób na programowanie GUI, ale Seed jest całkiem niezły do małych skryptów. Do większych programów lepiej wygląda Vala.

      "Widgety, gdzie naturalne są obiekty i klasy, mają gówniane API w C do tego z badziewnym hackiem na brak klas w postaci GObjectu."
      W C można programować obiektowo, choć ze względu na brak bezpośredniego wsparcia w składni jest to dość męczące dla programisty. Znacznie naturalniej programuje się w języku który z góry zakłada obiektowość.

      "A Qt ma skryptowanie w standardzie plus bindingi do Pythona (PyQt). Polecam. "
      Gtk+ też ma biding do Pythona :)
      W Pythonie całkiem fajnie pisze się w QT (Gtk jeszcze nie używałem z Pythonem). Niestety nie można tego powiedzieć o C++. Z kolei pisanie w JavaScript w QT jest trochę dziwne i niewiele ma wspólnego z pisaniem skryptów dla przeglądarek. W Seedzie pisze się tak jak dla zwykłej przeglądarki (poza elementami wziętymi z GTK).

    • Jak dla mnie kod C++ pod QT jest cudowny. Obiektowość, polimorfizm – to powoduje, że kod jest przejrzysty i łatwy do modyfikowania i rozszerzania. Poza tym, QT ma jedną, olbrzymią przewagę – kodzisz na wszystkie 3 platformy za jednym zamachem. Jak wejdzie nowe QT5 z QtQuick to będzie bajka dla koderów.

    • mikolajs

      Qt jest całkiem niezłe. Nie podoba mi się że qmake wykonuje za moimi plecami łączenie sygnałów, ale za to dzięki właśnie qmake kod xml UI zamienia się w kod C++ gdy Glade dla innych języków niż C nie ma takiej możliwości.
      Tyle, że samo C++ nie jest cudowne. Widocznie nie programowałeś w innym języku np. Javie, Vala czy w C#
      Pomijając już męczącą składnię, zobacz chociażby na przykładzie stringów jak nieciekawe jest programowanie w C++. Jak chcę pracować z QT to muszę używać klasy QString, jak przechodzę na WT (witty), to muszę się przestawić na WString itd. W każdej bibliotece co innego. Ten język nie dorobił się nawet na tyle dobrej biblioteki stringów, aby wszyscy mogli jej używać w różnych projektach. I tak jest z wieloma bibliotekami. A panowie od standardów zamiast pomyśleć nad jakąś konsolidacją to dodają nowe super ficzery. Przykładowo w PyQT operujesz na normalnych stringach Pythona.

    • Garrappachc

      qmake łączy sygnały, ale jeszcze się na nim nie zawiodłem. Niby jest to metoda callback-orientated, ale nie ma żadnych problemów z obiektowością czy argumentami. Poza tym, qmake sprawia, że pisanie programów staje się naprawdę łatwiejsze.
      Pisałem w Javie i wiem, jak bardzo utrudnić życie może brak możliwości przeciążania operatorów (kod jest mniej czytelny) czy brak operatorów domyślnych. Nie wiem, to tylko moje zdanie, ale dla mnie Java była dużo mniej wygodna niż C++.
      A stringi C++ wynikają z samej niskopoziomowości języka. String to dalej tablica charów i wszystkie operatory + (czy % w przypadku QStringa) wykonują dużo operacji na pamięci. Jest std::string i byłby fajny, gdyby nie to, że jest dosyć ograniczony. QString ma po prostu dużo więcej metod które czynią pisanie programów szybsze i wygodniejsze. Na szczęście, każda szanująca się klasa ma swoje metody konwertujące.

    • MikolajS

      Qt faktycznie ułatwia pisanie w C++, ale też nie wszystko da się napisać w Qt i wyjście z niego jest bardzo bolesne dla programisty C++

      " Pisałem w Javie i wiem, jak bardzo utrudnić życie może brak możliwości przeciążania operatorów (kod jest mniej czytelny) czy brak operatorów domyślnych. Nie wiem, to tylko moje zdanie, ale dla mnie Java była dużo mniej wygodna niż C++."
      Tak często przeciążasz operatory? Pisze dużo w Scali, gdzie możliwość tworzenia nowych operatorów jest dużo większa niż w C++ i rzadko kiedy to wykorzystuje. Patrząc na inne zalety Javy, ten brak jest niewielki. W C++ męczące jest pilnowanie plików nagłówkowych, konieczność pracy z dwoma plikami zabija inne zalety, ale to nic w zestawieniu z ręczną kotrolą nad pamięcią. Nie szukałeś nigdy, miejca wycieku pamięci? A czyszczenie pamięci po wyjątku? Jedyny powód jak dla mnie, aby pisać w C++ to mniejsze wykorzystanie zasobów komputera.

      " A stringi C++ wynikają z samej niskopoziomowości języka. String to dalej tablica charów i wszystkie operatory + (czy % w przypadku QStringa) wykonują dużo operacji na pamięci"
      W C++ stringi są mniej niskopoziomowe od tych z Javy. Początkujący programista może o tym nie wiedzieć :-) std::string to kontener char i dlatego nie jest zbyt wydajny choć może być wygodny, ale zawsze można korzystać ze stringów z C.
      Gdyby QString użyto jako podstawe standardowy string to byłoby super, a tak to musisz bawić się w konwersję np QString -> std::string -> WString itd nie jest to wygodne.

    • Nawet jeżeli sam nie korzystam zbyt często z przeciążania operatorów, to wystarczy, że biblioteki, których używam korzystają. Chociażby taki QString – operator + i sprawa jest prosta.
      Zaimplementowanie trackera pamięcia (przeciążając chociażby globalnie operator new) jest w C++ banalnie proste, a ja sam mam większą świadomość tego, co się dzieje z programem. Z wyjątków w C++ nie korzystam, bo są niewydajne, a ja uważam, że są lepsze sposoby wyrzucania błędów.

    • MikolajS

      String w Javie też ma + :-)
      Aby uzyskać coś co Java (a nawet Vala) ma od razu w C++ musisz się napracować. Podobnie z wyjątkami, obsługa błędów w inny sposób zabiera dużo czasu i później używający Twojego kodu może mieć problemy ze zrozumieniem jak to działa.

    • sprae

      A mój klucz francuski jest prześliczny.