added the field 'button' to key events.
the reason for calling it 'button' is so that it has the same name as mouse events.
the value is the translation as returned by XLookupString.
I've added the two methods addButton and setButtonPattern to the Application class.
the area in the background has to be paintable, not transparent, or the
button will not be displayed nor be sensitive.
patterns are taken from the application and are not stored with the button.
it might be a good idea to introduce an object hierarchy for widgets,
including Labels and Buttons, maybe also flashing buttons, but as far as the
application programmer (of things like the current examples) is concerned,
this is good enough, I'd say.
I've added the class pywmgeneral.Drawable, offering an interface to pixmaps.
this way a wmdocklib application can have more than one drawable: not only
the main window, but as many pixmaps as are necessary.
the first use of pywmgeneral.Drawable is to hold the graphical
representation of the labels in an application. Labels are also new to the
library and the intention is that they substitute the putString methods.
Application.addLabel() is used to create a new named label. the label takes
care of the specified area, or of the area necessary to show the specified
string.
Application.setLabelText() is used to specify a new text for a label. if
necessary, a new pixmap is created. the area taken care of by a label
cannot be modified.
during the update cycle, labels that span an area which is too small for
their text are scrolled a pixel at a time.
pywmradio.py uses this functionality.
example pywmphoto rewritten.
modified initializer of pixmap: you can give the name of the pixmap
containing the background/patterns, so you do not need reading it in
advance.
l'idea di separare lettera e accento non è proponibile in quanto troppo
complicata oltre che limitata. quindi semplicemente definire la mappa dei
caratteri! lavoro noioso e ingrato. l'ho già fatto per il set 6x8, mentre
ho usato uxterm per copiarmi i suoi set di caratteri, ma sono quasi tutti
troppo grandi (alti). l'unico secondo me davvero utilizzabile è il
5x8-utf-8 (già aggiunto), gli altri li sto aggiungendo ora e sono:
6x11-utf-8, 7x14-utf-8, 8x13-utf-8, 9x18-utf-8.
la libreria fa finta che il set di caratteri contenga tutti i caratteri possibili e immaginabili, se non ci sono, pazienza.
aggiunti due set di caratteri con tutti i caratteri fino al numero 384.
per l'Europa dovrebbe bastare.
livello della cache: blocco alto tre linee.
la barra di contacting/buffering si sposta più lentamente.
scelto un rosso meno scuro.
ancora sul livello della cache:
corretto errore nella espressione regolare (leggeva il carico cpu invece della cache).
aggiunto bordino a barra della cache.
uso dell'indicazione della configurazione per la dimensione della cache.
aggiunto metodo per mettere lo stream in pausa.
lettura del file di configurazione in utf-8.
pyradio, ma quella non è un'applicazione scritta con pywmdockapps)
modificato Application.update, ora ricalcola il livello di riempimento della
cache solo una volta ogni tre cicli (ogni 0.3 secondi), questo per abbassare
il carico di lavoro sulla cpu.
rimossa l'eccezione se un carattere non rientra fra 32 e 127.
quello che succede è dipendente dall'encoding del file da cui vengono lette le stringhe.
nel test case le óńł occupano due caratteri, che vengono saltati e resta
quanto era stato scritto prima. forse si potrebbe prevedere una separazione
"lettera"/"accento", però devo trovare il modo di definire l'accento in modo
che sia sovrapponibile alla lettera, mentre quelli che ho ora le
cancellerebbero.
alla fine dell'alfabeto potrei aggiungere gli accenti su trasparenza...
acuto (é) grave (è) tilde (ẽ) circonflesso (ê) breve (ĕ) lungo (ēħ) v (č)
punto (ż) dieresi (ë) coda-destra (ę) coda-sinistra (ç) obliquo (ł) o (å)
resterebbe il problema di caratteri quali ß æ œ ...
added new example application, on the way to the object oriented library.
the idea is to develop this program within one single source, but clearly
separating the general from the specific. so in this source I will have a
general 'Application' class which will contain no specific 'radio' code.
the radio code will make use of the general application class.
the program is not yet functional.
it really was a library problem... it was caused inside getFont by the way
I was choosing an alternative to a clashing character code. the correct way
is by choosing outside both the already defined characters and the
characters that the font uses. we were creating a cascade in clashes, and
were not able to handle it correctly. avoiding the problem is the best
cure.
