Zmiana środowiska graficznego

Chyba nadeszła ta chwila kiedy to w końcu trzeba zmienić środowisko graficzne … po prawie pięciu latach spędzonych na Fvwm-Crystal nadeszła chyba pora na zmianę.

Jakie są przyczyny ? Osobiścnie nie narzekam na Crystala jest:

  • mały
  • szybki
  • poręczny (jeżeli się już nauczy podstawowych skrótów)

Ale posiada jedną bardzo wielką wadę … wszystko było by OK gdyby nie to, że zachciało się mi podłączyć zewnętrzny monitor. W tym momencie Crystal (konkretniej mówiąc pages czyli przestrzenie robocze) wariuje, wyświetlane jest jednocześnie “półtorej” przestrzeni roboczej (tj. cała aktywa i kawałek następnej). Próbowałem nawet restartować i przeładowywać recepturełale to jeszcze pogorszyło efekt …

Tak więc staję znowu przed pytaniem “jakiego WMa wybrać”. Nie jest to dla mnie pytanie proste … bo szczerze mówiąc nie znam nic innego 😉 Jedno wiem na pewno, nie będzie to ani KDE ani Gnome.

Dla ścisłości … jakie wytyczne musi spełniać nowe środowisko:

  • możliwość konfiguracji do 12 przestrzeni roboczych i przełączanie się między nimi przez <alt>+F[1-12] (lub <win>+F[1-12])
  • możliwość przełączenia się pomiędzy dwoma sąsiadującymi przestrzeniami przy pomocy <alt>+[ i <alt>+]
  • możliwość przełączenia się pomiędzy dwoma ostatnio używanymi przestrzeniami za pomocą <alt>+<esc>
  • możliwość ciągłego podglądu wszystkich przestrzeni roboczych tj. tego co jest na nich odpalone (w Crystalu mam na prawej krawędzi pasek który reprezentuje wszystkie przestrzenie robocze oraz aplikacje na nich odpalone oczywiście umożliwia on również przełączanie pomiędzy przestrzeniami)
  • brak żadnych pasków zadań i menu (jedno menu “ekranowe” tj. po kliknięciu LMB w pulpit)
  • możliwość zdefiniowania aplikacji które mają się odpalać automatycznie
  • możliwość maksymalizacji okna poprzez <alt>+=
  • możliwość zdefiniowania od jakiego rozmiaru ma być zmaksymalizowane okno
  • nie powinno się rozjeżdżać po podłączeniu zewnętrznego monitora

oczywiście wszystkie te funkcjonalności nie muszą być od razu dostępne ale dane środowisko powinno być na tyle konfigurowalne żeby umożliwić mi ustawienie wszystkich tych opcji ale też nie chcę tonąć w plikach i skryptach konfiguracyjnych …

Cóż, poszukiwania czas zacząć … może ktoś pod powie parę ciekawych środowisk ? ;>

GWT 1.6m2 … duże zmiany

Sesja sesją, ale w między czasie umknęły mi dwa w miarę ważne wydarzenia … myślę tutaj o 2 milestone’ach GWT 1.6.

Nie ma co tu ukrywać trochę czasu minęło, nie jest to już nowinka … ale wprowadzone zmiany w najnowszej wersji Google Web Toolkit są dość spore.

Przede wszystkim trzeba tutaj wymienić zmianę podejścia do reakcji na zdarzenia. W najnowszym GWT  zrezygnowano ze wzorca obserwatora (observer pattern) na rzecz podejścia zdarzeniowego. Dodatkowo można programowo (z kodu Java’y) wywoływać zdarzenia systemowe (takie jak np. kliknięcie na przycisk) na widget’ach, w poprzednich wersjach nie było to możliwe.

GWTSchell i GWTCompiler zostają zastąpione przez HostedMode i Compiler. Dodatkowo w HostedMode zostało zastosowane Jetty (zamiast Tomcat’a) oraz dodano, jakże przydatną funkcję (jeżeli zmienia się implementację serwisów RPC lub przesyłanych encji), restartu servlet contener’a bez konieczności restartu całej aplikacji.

Kolejną ważną zmianą jest zmiana struktury katalogów w war’rze, rezygnacja z ogólnego katalogu public.

Wprowadzono dwa nowe widget’y:

  • DatePicker – jak sama nazwa mówi służy do wyboru daty
  • LazyPanel – załaduje zawartość panelu po pierwszej interakcji ze strony użytkownika

Standardowo,  poprawiono wydajność generowanych java script’ów oraz błędy.

To na tyle szybkiego przeglądu, więcej informacji można znaleść tutaj, a samo GWT zassać można z tąd … trzeba będzie znaleść chwilę czasu żeby się przyjrzeć bliżej nowej wersji GWT 😉

cda2mpc

Parę dni temu postanowiłem zgrać moją skromną kolekcję płyt audio do formatu MPC. Nie chcąc marnować czasu (i zaśmiecać systemu zbędnym softem), postanowiłem napisać sobie mały i prosty skrycik w Python’ie. Założenia

  • prostota
  • automatyczność (wkładam płytę odpalam skrypt i zapominam … ;))
  • zapis wyjściowych plików w pewnym ustalonym schemacie katalogów (wykonawca, nazwa albumu i utworu pisana camel case’em dodatkowo nazwa utworu poprzedzona jego numerem oraz praw dostępu: 400 (dla utworów_ i 500 (albumu))
  • automatyczne pobieranie informacji o utworach bez konieczności ich przepisywania (tj. wykorzystanie CDDB, a konkretnie cddb-py)

Oto efekt (należy pamiętać żeby podmienić baseDir !):

#! /usr/bin/python
 
"""
cda2mpc, Copyrighted, 2009
Ripps directly from CD audio to musepack (mpc) format.
Developed by Dariusz Luksza 
License: GPL v2
"""
 
import CDDB, DiscID, re
from sys import stdout
from string import capitalize
from os import chmod, makedirs as mkdir
from subprocess import Popen, PIPE, call
 
baseDir = '/home/lock/muzyka/'
 
def camelCase(value):
    return "".join([capitalize(w) for w in re.split(re.compile("[ _]?"), value)])
 
print 'Getting CDDB info ...',
stdout.flush()
cdrom = DiscID.open()
discId = DiscID.disc_id(cdrom)
 
(queryStatus, queryInfo) = CDDB.query(discId)
 
if isinstance(queryInfo, list):
	queryInfo = queryInfo[0]
 
(readStatus, readInfo) = CDDB.read(queryInfo['category'], queryInfo['disc_id'])
 
album = queryInfo['title']
splitAt = album.index('/')
 
artist = album[:splitAt - 1]
album = album[splitAt + 2:]
print ' DONE.'
 
print 'Starting to encoding:', artist, '-', album
 
saveDir = baseDir + camelCase(artist) + '/' + camelCase(album) + '/'
try:
	mkdir(saveDir, 0700)
except OSError:
	pass
 
for i in range(discId[1]):
	title = readInfo['TTITLE' + `i`]
	wavTrack = saveDir + 'track.wav'
	fileName = saveDir + `i + 1` + '-' +camelCase(title) + '.mpc'
	print '\tEncode track:', title , ' (', `i+1`, '/', discId[1], ')'
	print '\t\tStage 1 (wave) ...',
	stdout.flush()
 
	p = Popen(['cdparanoia', '-q', `i + 1`, wavTrack], stdout=PIPE)
	p.wait()
	if p.returncode is not 0:
		print ' ERROR!!'
		continue
	print ' DONE.'
	print '\t\tStage 2 (mpc) ...',
 
	stdout.flush()
	mpcCmd = ['mppenc', '--deleteinput', '--xtreme', '--silent', '--artist',
			artist, '--album', album, '--title', title, wavTrack, fileName]
	p = Popen(mpcCmd, stdout=PIPE, stderr=PIPE)
	p.wait()
	if p.returncode is not 0:
		print ' ERROR!'
		continue
	chmod(fileName, 0400)
	print " DONE.\n\tCOMPLETED."
 
chmod(saveDir, 500)
print 'COMPLETED.'
call('eject')

pommed-1.25 suspend on lid

Pommed jest deamon’em umożliwiającym korzytanie z mac’owych klawiszy funkcyjnych (tych od ściszania czy rozjaśniania ekranu lub też od manipulacji głośnością) obsługuje również wbudowane czujniki oraz zmianę intensywności podświetlenia klawiatury … oraz potrafi przyciemnić ekran kiedy się odłączy zasilanie … właśnie ta funkcjonalność wzbudziła moje zainteresowanie …

Dlaczego, skoro już obsługiwanie jest zdarzenie odłączenia od zasilania, nie obsługiwane jest zdarzenie zamknięcia klapki (tzw. LID). IMHO przejście w stan uśpienia było by najrozsądniejszym rozwiązaniem reakcji na zamknięcie przez użytkownika wieka laptopa.

Chwila grzebania w kodzie programu ujawniła, że takie rozwiązanie nie jest intuicyjne dla autora aplikacji, lub z jakiś powodów zostało odrzucone w procesie developmentu … domyślnie pommed w wersji 1.25 w reakcji na zamknięcie klapki … wyłączy podświetlenie klawiatury, oczywiście jeżeli takowe jest obecne w tam modelu mac’a. W przypadku kiedy nie posiadamy podświetlanej klawiatury zdarzenia LID są  ignorowane … szkoda bo można to wykorzystać w inny sposób.

Tutaj dostępny jest patch dodający możliwość konfiguracji zdarzenia LID. Domyślnie po opuszczeniu klapki zostanie wykonana komenda pm-suspend. W gruncie rzeczy może to być dowolna komenda która piszemy w pliku konfiguracyjnym … to chyba na tyle.

Ten sam patch wysłałem również do autora aplikacji … może poprawi moje błędy (bo w C nie pisałem już od wieków ;>) i jakoś dodatkowo rozwinie ta funkcjonalność.