Na początek Qt Designer, bo jego wcześniej się nauczyłem. Interfejs jest podobny do GIMP-a, czyli dużo niezadokowanych okienek: z kontrolkami, z właściwościami, ze slotami, z hierarchią kontrole i oczywiście okno naszego projektu. Glade natomiast to w całości jedno okno. Wiele osób narzeka na ten “gimpowy” interfejs, jednak w tym przypadku Qt Designer ładnej wygląda, chociaż może niestaranności wykonania Glade’a (głównie chodzi o okno z właściwościami, które, jak to trafnie pan w video tutorialu ujął, it’s never wide enough).

Wśród kontrolek Designera mamy pełen zasób biblioteki Qt (w tym np. kontrolka przeglądarki WWW opartej na WebKicie), jednak są to tylko stricte widżety. Nie będziemy mogli zdefiniować modelu dla *View (TreeView, ListView, etc.), a na tych kontrolkach miałem oparte oba interfejsy projektów (w sumie obie były pewnym interfejsem bazy danych). Glade potrafi tworzyć modele (o ile oczywiście wybierzemy projekt GtkBuilder, ale libglade nie jest już rozwijana, więc wybór tego pierwszego powinien być jasny), jednak chwilę musiałem pogooglać, jak to się robi. Jest to póki co mało intuicyjne (przynajmniej dla mnie). Natomiast w Designerze łatwiej udało mi się ustawić “sortowalność” kolumn (w sumie to w Glade jeszcze do tego nie doszedłem, choć próbowałem).

Ogólnie lepsze wrażenie sprawia jednak Designer. Jest bardziej intuicyjny, pozwala przenosić kontrolki myszką (nie trzeba ich wycinać albo zmieniać albo wpisywać pozycji we właściwościach) i edytować je na oknie. Od razu mamy także podgląd naszego okna. O wiele prościej się też moim zdaniem obsługuje kontenery, choć na początku miałem trochę trudności. W Glade trzeba trochę się namęczyć, żeby stworzyć pożądany efekt na okienku, żeby wszystko było równiutko.

To, co mi się jeszcze spodobało w Designerze, to sloty, chociaż to bardziej kwestia Qt niż samego Designera. Sloty bardzo ułatwiają podpinanie sygnałów. Możemy np. sygnał “clicked()” przycisku podpiąć pod slot “show()” okienka bez pisania żadnej procedury obsługi. Natomiast sygnały niestandardowe, które wymagają odrobiny naszego kodu, trzeba podpinać ręcznie (w kodzie). Glade potrafi zapamiętać nazwy naszych handlerów i automatycznie je podpiąć (w Pythonie trzeba jednak podać mu słownik odwzorowań nazw na funkcje jako argument).

Kiedy już stworzymy interfejs, nadchodzi etap programowania. Sama obsługa naszego interfejsu lepsza jest jednak w Glade. Tworzymy obiekt GtkBuilder i ładujemy nasz plik *.glade. Następnie wywołujemy funkcję, której podajemy nazwę widżetu, a ona zwraca nam wskaźnik (w Pythonie referencję) do niego i już możemy go używać. W Qt Designerze musimy odpowiednim narzędziem skonwertować nasz plik *.ui na kod źródłowy z klasą, od której nasze okno dziedziczy (lub enkapsuluje jej obiekt).

Co zatem jest lepsze? Oba programy są dobre. Na obu oparto potężne środowiska graficzne, zatem oba nadadzą się do stworzenia Twojego projektu. Każda ma swoje mocne i słabe strony, więc wybór w tym przypadku będzie indywidualny i często przypadkowy (tzw. kwestia gustu).

UPDATE: Glade jednak potrafi przenosić kontrolki, a Qt dynamicznie ładować interfejs.

% lspci
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)
00:01.0 PCI bridge: Intel Corporation Mobile PM965/GM965/GL960 PCI Express Root Port (rev 0c)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)
00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 6 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 03)
01:00.0 VGA compatible controller: nVidia Corporation GeForce 8400M GS (rev a1)
02:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 01)
07:09.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 05)
07:09.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22)
07:09.2 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 12)
07:09.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 12)
07:09.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev ff)

I installed Debian Squeeze amd64 and almost everythinng worked out-of-box, except few things.

Wi-Fi
I had to install binary firmware for Intel 3945 since non-free packages are not in default Debian installation. Fortunately I was able to connect with wire:

sudo aptitude install firmware-iwlwifi

NVIDIA drivers
The default X driver is nv which performance is poor. Again, I had to manually install non-free software. Just googled “nvidia drivers linux” and followed the instructions. The good news is that the quailty of the official NVIDIA drivers for X server is very satisfactionary.

Muting speakers when headphones are plugged-in
This is one I haven’t solved yet. I just mutted the front speakers in ALSA Mixer, but that’s only a workaround.
UPDATE: It works after updating alsa-base to version 1.0.20

ACPI
I noticed that when I tried first time to exhaust the battery it didn’t show any notification like “Low battery level”; it just died out of energy. Maybe it’s just a GNOME setting, dunno.

What I haven’t tested is fax modem and card bus.

The battery works for 2h15m which is quite short time.

Zanim zaczniesz

Musisz najpierw skompilować program z informacjami dla gdb. Robi opcja -g dla gcc.

Komendy

Zamiast miłego interfejsu graficznego, jest miły wiersz poleceń (co dla programisty jest wygodniejsze, bo nie musi odrywać rąk od klawiatury :>), w którym wpisujesz polecenia. Nie musisz podawać jej pełnej nazwy, wystarczy jednoznaczny początek (najczęstsze polecenia mają jedno/dwuliterowe synonimy). Działa dopełnienie tabulatorem! W razie czego: help komenda.

Start

Pierwszy paremtr to nazwa pliku wynikowego programu. Drugim może być numer procesu tego programu, jeśli chcesz zacząć debuggować już działający program.

Przydatne komendy:

• run [argumenty] –  uruchamia program z podanymi (opcjonalnymi) argumentami
• continue – jeśli program jest zatrzymany, wznawia jego działanie
• finish – program się wykonuje aż do napotkania “return”; innymi słowy program działa aż do końca aktualnej ramki stosu

Stop

Żeby się gdzieś zatrzymać, trzeba ustawić breakpointy:

• breakpoint funkcja – ustala breakpoint na początek funkcji
• breakpoint [plik:]linia – ustala breakpoint na określoną linię pliku
• info breakpoints – wypisuje utawione breakpointy
• delete n – usuwa n-ty breakpoint
• condition n cond – ustala warunek dla n-tego breakpointa (program zatrzyma się na nim, jeśli zostanie spełniony warunek cond)
• ^C - czyli przerwanie z klawiatury, również zatrzymuje działający program i oddaje kontrolę gdb

Co się dzieje?

Kilka przydatnych komend, aby zorientować się, co się aktualnie dzieje:

• list – listing kodu (10 linii obecnego kontekstu, podana nazwa funkcji, numer linii, etc.)
• frame – aktualna ramka stosu oraz aktualna instrukcja
• backtrace – ślad stosu
• print x – wypisanie wartości x (to może być dowolne wyrażenie, razem ze zmiennymi w programie)

Tropimy

To, co najważniejsze, czyli śledzimy program krok po kroku:

• next – następna instrukcja (lub n instrukcji), bez wchodzenia wgłąb procedur
• step – j/w, ale z wchodzeniem wgłąb

Psujemy

Można przetestować kilka rzeczy w trakcie trwania programu:

• set x wartość – ustawiamy zmiennej x wartość
• call f(x) – wywołujemy funkcję f z argumentami (w tym wypadku tylko x)

Format zapisu zmiennych, funkcji i adresów.

Czasem chcemy się odwołać do zmiennej z jakiegoś innego zakresu albo funkcji składowej, wtedy piszemy zakres::x, jeśli np. zakres jest klasą, a x jej metodą/polem, albo zakres jest funkcją, a x jej zmienną lokalną. Odwołanie do konkretnej linii ma składnię plik:linia, np. test.c:244. Adres zapisujemy z gwiazdką na początku, np. *0×000000.

A na koniec: quit. I tyle. To było zaledwie 1/5 możliwości gdb, mimo to spokojnie wystarczy do efektywnego debuggowania. Chociaż dziesiątki printfów mają swój urok. ;)

Załóżmy,  że jakiegoś programu używa 200000 osób, jedna na tysiąc programuje, więc daje nam 200 programistów, zdolnych przejrzeć i poprawić nasz program. Korzystają wszyscy, nie tylko informatycy. Na tym to polega. Jasne? Mam nadzieję, że cześć osób zrozumie.

It is almost ended. It doesn’t only check local variable if they have unique names. I’m too lazy to do that. But after all it works fine and quite fast (compared to other interpreters written by my colleagues).

To run jzwi program just run “jzwi program.jzw argument1 argument2 …”.

It’s all licensed on GPL (any version). There is no guarantee that it’ll work. ;)