Witam. W kolejnym odcinku "A co mnie obchodzi czego używa Vifon?!" chciałbym przedstawić niedawno przeze mnie poznany manager plików - ROX-Filer.

ROX-Filer został stworzony na potrzeby środowiska ROX Desktop. Z tego drugiego nigdy nie korzystałem i jakoś nie widzę siebie w tej roli, ale sam manager plików wydał mi się bardzo interesujący.

Co takiego go wyróżnia? Idealne połączenie prostoty z zaawansowaniem! Interface wygląda tak:

Wygląda bardzo prosto i - o ile zostaniemy jedynie przy podstawowych funkcjach - takie właśnie jest, ale pod pozorną prostotą kryje się prawdziwy skarb dla power userów.

Przykładowo, możemy włączyć, żeby podczas przeciągania plików otwierało się tymczasowe okno z zawartością kolejnych katalogów, na które najedziemy. Dzięki temu, możemy, używając jedynie jednego okna, przenosić pliki po całym systemie plików. Co ciekawe, można też przeciągnąć plik na ikonkę domku na górnym pasku, co zostanie potraktowane jak przeciągnięcie na faktyczny katalog domowy (może też otworzyć wspomniane okno tymczasowe, o ile włączyliśmy tę opcję).

Czym byłaby seria wpisów o managerach okien bez dwma i jego pochodnych? Pisałem już kiedyś o awesome, ale takich managerów jest więcej (wbrew przesadnie onetowemu tytułowi tamtego wpisu...). Omówię je raczej powierzchownie, nie miałem czasu by je wszystkie dogłębnie przetestować. Skupię się na najbardziej widocznych różnicach.

Cechy wspólne

Wszystkie managery wywodzące się z dwm są dość charakterystyczne:
- okna są rozmieszczane w pełni automatycznie. Jest kilka układów, które można zmieniać, można zamieniać okna miejscami i można w pewnym stopniu zmieniać ich proporcje. To tyle, reszta dzieje się sama,
- raczej nie mają graficznych konfiguratorów - przeważnie używa się plików konfiguracyjnych pisanych w poważnych językach programowania. Daje to bardzo duże możliwości konfiguracyjne,
- nacisk jest położony na obsługę klawiaturą.

Bez wnikania w szczegóły, dwmoidy różnią się między sobą głównie językiem w jakim się je konfiguruje i często paskiem informacyjnym.

dwm

Konfiguracja dwm to zwykły C.

W ostatnim wpisie pisałem o wmii, więc myślę, że to dobra pora by omówić podobny manager okien, który czerpie z niego całymi garściami dokładając też sporo od siebie - i3.

wmii++?

Zacznę może od podobieństw do wmii. i3 "pożyczył" od niego dynamiczne zarządzanie tagami, jak i ręczne pozycjonowanie okien. Tym razem jednak okna nie są umieszczone w kolumnach, lecz mają strukturę drzewa - każdą "komórkę" można rozgałęzić na dwie czy więcej kolejnych. Ciężko to opisać, dlatego poniżej umieściłem stosowny screenshot. Przyznam, że takiej swobody rozmieszczania okien nie widziałem jeszcze w żadnym podobnym managerze okien. Niestety ma to swoją cenę - złożoność. Często trzeba się dobrze zastanowić co musimy zrobić, żeby okno wylądowało tam, gdzie chcemy. Możliwe, że po dłuższym czasie można do tego przywyknąć, ale ja nie miałem tyle cierpliwości. Mimo wszystko - ciekawe rozwiązanie z dużym potencjałem.

Jeśli zaś chodzi o dynamiczne tagi, to niestety, ale wmii realizował to znacznie lepiej.

Jakiś czas temu pisałem o jednym z tzw. tilingujących (ang. tiling) managerów okien - awesome. Przyznam, że wtedy jeszcze nie siedziałem aż tak w tym temacie i nie byłem świadomy ile jest managerów okien o podobnej filozofii. Dzisiaj chciałbym Wam przybliżyć inny ciekawy okaz - wmii.

Uwagi wstępne

Zanim się zagłębię w działanie tego managera, mam kilka uwag. Każdy skrót klawiszowy wykonuje się z klawiszem Super (ten z logiem Windowsa) lub Altem. Z którym - to już zależy od wyboru przy pierwszym uruchomieniu. Każdy wymieniany przeze mnie skrót wykonuje się z tym klawiszem, o czym nie będę za każdym razem powiadamiał. Dla uproszczenia będę też czasem używał skrótu "wm" - window manager.

Kolumnada okien

W wmii podstawową jednostką organizacji okien jest kolumna. Można mieć kilka okien w jednej kolumnie, można mieć kilka kolumn (z kilkoma oknami) obok siebie. Da się dość swobodnie przekładać okna między nimi czy zmieniać kolejność okien w obrębie jednej kolumny.

Od kilku tygodni jestem szczęśliwym użytkownikiem Arch Linuksa. Przed nim przetestowałem kilka innych dystrybucji. Oto moje przemyślenia.

Przesiadkę planowałem od niemal roku. Pierwotnie chciałem przejść na inne distro, ale w międzyczasie zmieniłem zdanie dwukrotnie. Co uważniejsi może kojarzą jakiegoś userka plączącego się w komentarzach do wpisów webnulla o popularnych distrach i wypytującego o to i owo (wtedy jeszcze byłem znany pod innym nickiem). Na początek odrobina historii.

Ubuntu

Wcześniej używałem Ubuntu 10.04 LTS*. Niby źle nie było, ale z czasem zaczęło robić mi się "ciasno". Jako że wszystko było względnie skonfigurowane, obawiałem się coś ruszać, żeby nie popsuć. Nie wiedziałem co jest ustawieniem domyślnym, a co już zostało skonfigurowane. Do tego, repo było dość... starawe. Planowane przez Canonical zmiany nieszczególnie mi przypadły do gustu, więc podjąłem decyzję, że trzeba się ewakuować.

Webnull może, to ja też - oto "reklama" odświeżonej wersji jednego z moich tworów. ;)

Może zacznę od krótkiej lekcji historii. Jakiś czas temu napisałem w zsh bardzo prymitywny generator Makefile'i - miałem dość ich ręcznego pisania, bo było to jedynie durne klepanie. Skrypt się rozrastał i rozrastał, aż w końcu stwierdziłem, że zsh jest dla niego "za ciasne". Postanowiłem przepisać go do jakiegoś ambitniejszego języka. Mój wybór padł na Perla i z perspektywy czasu (jednego dnia :P) myślę, że był to dobry wybór.

W międzyczasie miałem okazję wypróbować CMake, który niestety mnie do siebie nie przekonał. W prostych przypadkach, klepania jest równie dużo co w Makefile'u, a do tego więcej do zapamiętania. Przeraża mnie też ilość śmieci, jakie mi wypluwa do katalogu z programem. Widać, że przy bardziej skomplikowanym projekcie sporo ułatwia, ale taki przypadek rzadko mnie interesuje.

W poprzednim wpisie wspominałem, że będzie jeszcze coś o Emacsie. No to jest. Dość niespodziewany zwrot akcji, nawet dla mnie.

Myśl o poznaniu Emacsa chodziła mi po głowie już od wielu miesięcy. Jakieś podstawy znałem, ale niewiele ponad to. Co mnie skłoniło do przejścia do "obozu wroga" i jakie są moje przemyślenia?

Potrzeba rozwoju

Wiem, że brzmi to jak jakiś nonsens, ale jednym z moich większych problemów stała się przesadna znajomość Vima. Oczywiście nie wiem WSZYSTKIEGO, ale coraz rzadziej odkrywałem w nim coś nowego. Czułem, że potrzebuję nowego wyzwania. Jak się potem okazało, to wyzwanie mnie przytrzymało na dłużej.

Interakcja z zewnętrznymi procesami

Jedną z największych bolączek Vima jest brak możliwości interakcji z zewnętrznymi procesami bez dużego kombinowania. Najbardziej widać to, gdy trzeba debuggować jakiś program. Niby jest projekt Clewn, ale nigdy nie udało mi się go zmusić do działania. W Emacsie po prostu włączam M-x gdb i debugguję jakby nigdy nic.

Nareszcie jest długo wyczekiwane (jasne...) obiecane przeze mnie wprowadzenie do Vima. Miałem dość dużo na głowie, stąd aż trzy miesiące oczekiwania.

Na początek wyjaśniam, czym ten wpis NIE jest:
- spisem poleceń (jakby mało ich było w necie...),
- samowystarczalnym kursem Vima - chcę raczej uzupełnić lukę w innych kursach,
- czymś, co zrobi z czytelnika vimiatacza w 20 minut.

A czym jest? Opisem filozofii działania Vima i opisem często ignorowanych, a przydatnych poleceń.
Nie radzę kontynuować bez zaliczonego vimtutora lub znajomości podstaw. Możliwe, że część informacji się powtórzy, bo nie pamiętam już, co tam było, ale nie zamierzam wykładać najpodstawsiejszych podstaw.
Bardzo możliwe, że tempo będzie nieco zbyt szybkie. W razie czego, polecam po każdym większym fragmencie potestować omawiane polecenia. Bądź co bądź, to mój pierwszy wpis tego typu, więc na pewno coś spaprałem. Ostrzegam, może być nudno. Opinie mile widziane. ;)

Poruszanie się

Może się wydawać, że poruszanie się jest na tyle prostą czynnością, że można ograniczyć się do podstawowych przycisków. Ja się z tym absolutnie nie zgadzam.

Jak można było zauważyć w jednym z moich poprzednich wpisów, jestem wielkim fanem Vima. Na tle mojego poprzedniego edytora - Notepada++ - chciałbym pokazać jego najsilniejsze strony, jak również i wady.

Dostępność

Notepada++ przestałem używać jeszcze zanim porzuciłem Windowsa, więc nie przeszkadzał mi brak wersji na inne systemy. Mimo wszystko, jest to jedna z jego największych wad. Udało mi się go z powodzeniem uruchomić pod Wine, ale nie czułem się z takim rozwiązaniem komfortowo.

Vim jest dostępny na wszystkie znane mi "duże" systemy. Windows, GNU/Linux, Mac OS, BSD, Solaris i pewnie inne, o których teraz zapomniałem - na każdym z nich możemy bez problemu korzystać z tego samego edytora. Po części można go też używać np. na Symbianie, chociaż to trochę oszukiwanie. Mam na myśli korzystanie z niego przez protokół SSH. Obsługiwanie Vima na klawiaturze telefonu nie jest moim ulubionym zajęciem, ale co kto lubi - da się.

Niedawny wpis o komunikatorach skłonił mnie do refleksji nad upodobaniami Zwykłego Użytkownika.

Jakimś dziwnym trafem, ZU używają przeważnie najgorszych programów z ich kategorii. Przykłady? IE, wspomniane GG (i klient, i protokół), WinRAR (tutaj "gorszość" polega na tym, że są lepsze - i darmowe - alternatywy) czy Winamp/Windows Media Player.

Sprawa IE jest dość jasna, więc pozwolę sobie je pominąć.

Gadu-Gadu
Główną przyczyną sukcesu Gadu-Gadu jest wejście na rynek w dobrym momencie i swojsko brzmiąca nazwa. Sam protokół jest niesamowicie zacofany, a klient jest jednym wielkim słupem ogłoszeniowym. Przyzwyczajenie jednak robi swoje. ZU boi się zmian, więc nie ma mowy o alternatywnym kliencie czy protokole. I koło się zamyka.

WinRAR

WinRAR jest ciekawym przypadkiem. Zdecydowana większość jego użytkowników używa go, bo Znajomy Informatyk™ go polecił. No dobrze, a czemu ZI go polecił? Bo gdy zaczynał "karierę", to jego ZI mu polecił.