Zmiana Domyślnego menedżera okien w Gnome

Zmieniłem zdanie co do duetu Compiz + Beryl. To prawda, że wygląda fajnie i ma kilka przydatnych rzeczy usprawniających nieco pracę, ale ma również kilka wad. Największą z nich jest spadek wydajności systemu i zdarzające się czasem artefakty graficzne. Inną rzeczą jest spadek efektywności pracy. Takie piękne gumowe okienka czy inne cuda są wporządku, ale tylko do pobawienia się. Na dłuższą metę trzeba to wyłączyć ponieważ przeszkadza w szybkiej pracy.

Postanowiłem więc zmienić domyślny menedżer okien na domyślny dla Gnome – Metacity. Tutaj pojawia się problem. Jest milion możliwych sposobów na uruchomienie menedżera okien tak aby osiągnąć taki sam efekt. Niestety wszystkie, które mi przyszły do głowy były raczej pracą “odtwórczą” tzn.: “Pozwól Gnome się załadować i wtedy zmień menedżera”. W sumie rozwiązanie różni się od “dobrego” tym, że po zalogowaniu trzeba czekać o kilka sekund dłużej

Na szczęście można to zrobić tak jak by wypadało. Po pogrzebaniu  internecie znalazłem informację, że można X-Serverowi powiedzieć co powinien uruchamiać jak już się załaduje. To raczej oczywiste. Odpowiada za to linijka  “Exec= [...]” w pliku /usr/share/xsessions/gnome.desktop. (dla KDE jest kde.desktop). Zauważyłem, że domyślnie dla Gnome uruchamiany jest program /usr/bin/gnome-session. A to oznacza, że to on musi uruchamiać menedżera okien. Wpisałem więc w konsoli polecenie:

man gnome-session

I po krótkiej lekturze okazało się, że używa on pliku konfiguracyjnego w katalogu użytkownika: ~/.gnome2/session lub jeśli taki nie istnieje – domyślnego /usr/share/gnome/default.session. W moim przypadku miała miejsce druga sytuacja. W domyślnym pliku zobaczyłem wpis:

0,RestartCommand=gnome-wm --sm-client-id default0

Co prawda nic z niego nie rozumiem, ale gnome-wm daje do myślenia. Google podpowiedziało, że to ten program jest odpowiedzialny za uruchamianie menedżera okien. Ok – jesteśmy coraz bliżej

Teraz trzeba było poczytać manual do gnome-wm i mieć nadzieję, że gdzieś tam się znajdzie informacja o pliku konfiguracyjnym. Otóż taki nie istnieje Informacja o tym co uruchamiać na starcie znajduje się w “rejestrze” gnome’a:

gconf-editor

Odnajdujemy klucz /desktop/gnome/applications/window_manager/default i ustawiamy go na menedżer okien, którego chcemy użyć.

To takie, proste, a tyle było szukania… Ech… mam nadzieję, że przyda się to komuś kiedyś

Python: uruchamianie zewnętrznego programu

Załóżmy, że mamy program napisany w C++, który pobiera ze standardowego wejścia jedną liczbę, a następnie informuje nas jaką liczbę wpisaliśmy. Kod takiego programu wyglądałby pewnie tak:

#include
using namespace std;

int main()
{
    int in;
    cin >> in;
    cout < < "Wpisano liczbe: " << in << endl;
    return 0;
}

Teraz załóżmy, że chcemy taki program uruchomić z innego programu pisanego w C++. Już bierze was nerwica? Jeśli programujecie w Windowsie, to pewnie tak. W Linuxie nie jest to taki wielki problem bo łatwo można to zadanie zrealizować używając funkcji popen(). Tak czy inaczej w systemie z Redmond jest to prawdziwy pain in ass, że tak to ujmę…

W Pythonie z kolei kod wykonujący to zadanie jest nienaturalnie (dla programistów C/C++ przynajmniej) krótki i wygląda tak:

#!/usr/bin/python

import subprocess as sub

p = sub.Popen(["./a.out"], stdin=sub.PIPE, stdout=sub.PIPE, stderr=sub.STDOUT)

child_output, child_error = p.communicate(input="234")
print child_output

I w ten sposób można uruchomić zewnętrzny program przejmując kontrolę nad jego I/O we wszystkich systemach na których zaimplementowany jest Python. Cudowne prawda? ^^
Btw.: wiem, że za bardzo się zachwycam

Python: Ukrycie okna konsoli w Windows

Jedynym mankamentem jaki pojawił się podczas uruchamiania skryptu wykorzystującego GUI w Windowsie, było wyskakujące czarne okienko konsoli… Rozwiązanie tego problemu znalazłem dość szybko i jest ono niesamowicie proste. Otóż w instalacji Windowsowej istnieją dwa interpretery – jeden konsolowy (python.exe)  oraz jeden Windowsowy (pythonw.exe).

Aby skorzystać z tego drugiego podczas wykonywania własnego skryptu wystarczy zmienić rozszerzenie z .py na .pyw.

Po takiej zamianie okno konsoli już nie będzie straszyć użytkowników programu

Python on board

Ostatnio postanowiłem nauczyć się jakiegoś ciekawego języka skryptowego. Początkowo mój wybór padł na Perl’a… Po krótkim zapoznaniu się z nim i napisaniu małej aplikacji sieciowej postanowiłem go już nigdy więcej nie dotykać

Następny na liście jest Python. Jak dotąd okazuje się być całkiem prosty do zrozumienia i opanowania. Na sam początek napisałem krótki programik sieciowy, później zechciałem sprawdzić jak Python radzi sobie z GUI. Jak się okazało, napisanie prostego programu okienkowego jest bardzo proste. Początkowo trzeba mi było wybrać jakąś bibliotekę do tworzenia GUI. Jako, że z wxWidgets się znamy wybrałem dla Pythona moduł wxPython. Okazało się, że gdyby nie pewne różnice składniowe możnaby było wkleić tutaj kod z C++ wykorzystujący wxWidgets i pewnie też by działało

Wybierając wxPythona miałem nadzieję jeszcze na to, że będę mógł uruchomić mój skrypt pod Windowsem, ale nie wymagałem by działało to “z urzędu”. Trudno opisać moje zadowolenie w chwili gdy po instalacji w Windowsie Pythona i wxPythona oraz podwójnym kliknięciu na pliku skryptu moim oczom ukazało się dokładnie takie samo okienko jak pod Linuxem! Tak po prostu. Żadnej konfiguracji. Nawet nie musiałem restartować systemu. Piękne uczucie