2 prototipi di finestra di dialogo Undo - Close e Undo - OK

Vote my Idea to improve login manager capabilities

Please vote my Idea :)

"Auth against any of the OpenID/Yahoo/Google/Facebook/Twitter/Meemi... into your local login manager (when network is available otherwise use the classical mapped local login user). "

Click and vote

Packaging Gaim into ioGaim2.0 for feisty IOL2007

apt-get source OK
configure && make && make install OK
preparing Bundle package..
checking Icons...

Commento completo al post di pollycoke su home is my desktop

Si parla di home is my desktop
Mi ha troncato il commento e quindi lo proseguo qui per completezza
Post originale su Pollycoke

COMMENTO:
Mi rendo conto che /$HOME è hardcore, veramente esagerato.Bisognerebbe svolgere valutazioni in funzione del reale utilizzo della macchina.
In fondo esiste una netta separazione di utilizzo tra un PC casalingo monoutente (mono >= 1 AND 3 < mono < 1) ed un server multiutente.
Un PC casalingo normalmente potrebbe avere uno due utenti...(3...tiè facciamo 5 nonna compresa) insomma enumerazioni umane che non sfuggono dal controllo della nostra memoria a corto termine...ovvero complessita bassa.
E' meglio evitare di trovare l'unica soluzione che va bene per tutto...non è piu questo il giusto luogo di sviluppo della discussione.
Penso che nel caso pseudo monoutente (un tipico caso è l'iBook di turno della ragazza, la mia, che ci cataloga foto e musica ed un nminimo smanettamento tra files ed internet), ecco in questo caso il sistema dovrebbe offrire una vista piu Unixless possibile.
Il filesystem Unix FHS che conosciamo è un'architettura classica Database distribuita, insomma un tecnicismo bellissimo che ci fa godere...ma va bene per ambiti tecnici /etc?? /proc?? ma che vuol dire?? (si chiede la mia ragazza)...già chiamarli /Binary /Processes /Devices avrebbe ridotto l'attrito cognitivo...
Se root fosse /Root (dark zone dedicata a noi) gia avrebbe risolto un sacco di tutte queste chiacchiere che andiamo facendo!!!
Se non fosse per un desktop launcher (virtual proxy) o un desktop nel Menu Applicazioni (virtual proxy anch'esso) la Manuela e Lavinia se ne guarderebbero di andare in /usr/bin a cercarsi nientepopodimeno che "gimp"!!!Anzi a dirla tutta...non sanno manco che cosa vuol dire /usr/bin
Cosa è Unix per quegli utenti?? Uno stato assistenzialista (proxy launchers provided by distro vendors) che se fallisce li lascia per strada? (inconsistenza classica di quando non funziona qualche cosa sotto Linux e devo intervenire io che ci capisco!!!).
Insomma il problema dell'FHS esiste ed è grave e non c'è Gnome VFS che regge.
Usare due dischi Root + Home?? E' un ottima idea, ma la root è sempre li in agguato (la possiamo nascondere alla vista totale??).
======
======
Aggiungo di seguito il mio primo commento per completezza
PRIMO COMMENTO
Per 2 anni di seguito ho svolto test desktop==home su 2 utenti novizi (3 con me) ai tempi dove Ubuntu non esisteva manco nella mente del suo grande ispiratore.
E’ ,per me, sotto sempre il concetto piu logico derivato da alcune considerazioni topologiche:
1) Nell’utilizzo quotidiano degli oggetti, l’uomo comincia a perdere orientamento se super i 3 livelli di nesting.Guardatevi intorno e vedrete che è raro superare 3 cose infilate una dentro l’altra (oggetti in scatole in cassetti ad esempio).Questa è la nostra natura…al 4 livello di nesting sbrocchiamo!!!
2) Il monitor è il computer (parafrasando Sun e la sua “Il computer è la rete”). Sembrera assurdo, ma un normale utilizzatore associa a cio che vede nel monitor…il proprio computer in temini di dati etc etc (windows è una continua violenza a questo concetto…forse Vista è andato oltre), da cio emerge che gli oggetti creati nel Desktop sono gli oggetti del nostro mondo digitale (spatial desktop esiste proprio per assecondare questo concetto). Ovvero, di nuovo, il Desktop/ è la nostra root.
Nella situazione attuale dove la deficienza (nel senso di deficere) del Gnome VFS non permette una completa virtualizzazione del FS su TUTTE le applicazioni possibili (e quando mai potrebbe se queste ultime non si adeguano utilizzando almeno il file selector GTK?? e perche mai dovrebbero applicazioni QT/FLTK/TCL/TK etc etc aderire univocamente?) ci ritroviamo una continua inconsistenza della vista del FS all’utilizzatore finale tale che: desktop==home è pericoloso (anche se necessario) perche mischia tutte le directory puntate (esposte in un’inifinita di file selectors di altrettante librerie grafiche).
Insomma la mia visione è qualcosa del genere: tutte le configurazioni devono essere esposte in una cartella del tipo $HOME/Configurations (o qualcosa di simile) tale che $HOME è una zona pulita == Desktop, root dell’utente che puo sviluppare la sua entropia.
Tornando al punto 1 desktop==home è necessario perche al livello $HOME siamo gia al 3 nesting (che viene esposto alla vista dell’utente mentre tenta di navigare tra i files): /, /home, /home/$HOME
Nonostante lo Unixware che è in me (da non confondere con SCO UnixWare) andrei addirittura oltre.
porterei le $HOME direttamente sotto root (/luca, /marco, /barbara)…sto bestemmiando? Meditate gente…meditate…
Un mio esperimento veramente estremo ha dato ottimi risultati:
Un PC monoutente aziendale in mano ad una ragazza, Manuela con configurazione root is my desktop (e le adeguate policy di scrittura e hiding dei file) ha prodotto questo: 1 anno di utilizzo ininterrotto giornaliero senza mai corrompere un solo file in root che veniva nascosto alla vista utilizzando il .hidden
Zero livelli di nesting…utente==monitor==Desktop=Root FS==Computer
Dal punto di vista dell’usabilita quotidiana è stato il massimo, ma dal punto di vista dell’amministrazione aggiornamenti etc etc…un incubo.
;)

[The Road To...] Rebuild World?

La tentazione di ricostruire il mondo è immensamente grande.Non mi tornano mai i conti nel bilancio ricavato dal rapporto Benefici/Entropia.
Insomma queste distribuzioni Linux ed in particolare Ubuntu...sono ecologicamente insostenibili.
Apt è una spada di damocle per la materia duale che va dal layer GNU (escluso) in su.
Ai tempi del C64 riuscivo a programmare grafica usabile (con il joystick) che risultava pulita efficace e fluida.
Oggi con un banalissimo AMD 2800+ e 512MB di RAM devo subire lacune di rendering quando trascino le finestre di Nautilus da una parte all'altra dello schermo (cosa che non succede manco al piu cesso di Mac...ok ho esagerato!!!).
Il mondo dello sviluppo OpenSource è tutt'altro che ecologico e decisamente entropico.
Mi piacerebbe lavorare con un sistema composto da:
Layer GNU di base gestito da un sistema a prova di bomba come Apt.
Layer grafico X/framebuffer gestito da un sistema in stile port di BSD (ricompilazione/ottimizzazione/installazione) posto in un bundle separato.
Layer userland gestito direttamentre dall'utente con programmi non installanti in stile Bundles di OSX/*STEP/ROX/RISC OS.
Il lato GNU + Kernel deve contenere nativamente in modo completamente trasparente un sistema tipo OpenSSI

Non è da escludere riconsiderare per il layer GNU l'utilizzo di builder del calibro di NetBSD (54 piattaforme supportate) o T2


SYSTEM CRASH SAFE
Cerco di immaginare un gruppo di software collaborativo che faccia di tutto per mantenere integro il sistema.
Se il sistema si interrompe l'utilizzatore anche in emergenza deve essere in grado di riprendere il proprio lavoro portarlo a compimento e poi eventualmente recuperare il sistema principale corrotto.
Esempio:
Dopo aver fornito una distribuzione stabile, l'utilizzatore scarica nella memoria ulteriori programmi (Abiword e Gnumeric).
Durante l'uso di Gnumeric il sistema si blocca non permettendo piu il lavoro, a quel punto l'utilizzatore riavvia e direttamente da GRUB selezione una sessione specializzata di nome Gnumeric che si limita ad avviare un kernel separato con un X separato minimale e Gnumeric al top esclusivamente per permettere di lavorare direttamente e concludere il proprio lavoro.

[The Road To...] Windows Manager Changes

Reintroduco il tasto "Chiudi" posizionandolo nell'angolo a sinistra. Elimino il tasto Massimizza e lascio Minimizza nell'angolo a destra.
RATIONALE:
I controlli GTK generici richiedono, nelle loro varie configurazioni, anche la presenza del tasto Chiudi della finestra, diversamente l'utente potrebbe non riuscire ad usare completamente l'interfaccia in modo consistente.
E' un problema di integrazione tra le tecnologie che va risolto a monte..forse Freedesktop è il luogo ideale.
Doppio click sulla barra della finestra produce la massimizzazione.E' una funzionalita nascosta in quanto ridondante alla capacita di estensione manuale dell'utilizzatore.
In pratica la persona è in grado, utilizzando l'angolo in basso a destra della finestra, di modellare la stessa a proprio piacimento e quindi anche massimizzarla, ma non minimizzarla o chiuderla completamente.
Cosi ho deciso di esplicitare visualmente le due funzioni di Chiusura e Minimizazione tenendole adeguatamente separate tra loro per evitare errori dovuti all'imprecisione di puntamento.
Sfrutto, in questo caso, anche la legge di Fitts per migliorare la capacita di puntamento in quanto le due funzionalita sono agli estremi degli angoli della finestra.
Considerando che la chiusura della finestra è un evento disastroso, ponendo il tasto a sinistra (mentre normalmente lo si aspetta a destra grazie alla diffusione di Windows e OSX) l'utilizzatore ha a disposizione piu tempo per ragionare e controllare la compulsivita (conosciuta come click isterico).
Dai test che ho eseguito, risultano diminuiti i casi di chiusura accidentale della finestra.
L'eliminazione del pulsante di Massimizzazione pulisce l'interfaccia grafica riducendo la complessita.
La funzionalita è comunque presente usando il menu contestuale sulla barra della finestra e comunque cliccando due volte sulla stessa.

[The Road To...]

Quando Mario attiva la cache con io SpatialBundle questo deve rimanere autoconsistente attraverso l'uso di Maria ed altri utilizzatori.
Cio implica che le modifiche dinamiche al proprio Desktop devono avvenire TUTTE localmente in $HOME/.local
Devono essere eliminate le modifiche nella LiveDir.
Mario ha i diritti in scrittura nello ioSpatialBundle in caching quindi è l'unico che potrebbe scrivere nella LiveDir mentre Maria ha solo diritti in lettura rimanendo penalizzata in scrittura nella LiveDir.
La LiveDir viene eliminata a favore di un metodo dinamico in caching: DinamicCacheLiveDir presente in /tmp/ioSpatialBundle_DinamicCacheLiveDir_Maria/ costruita semplicemente con:
export PROGRAMMA=ioSpatialBundle
export PERSON=whoami
export CacheLiveDir=$PROGRAMMA"_DinamicCacheLiveDir_"$PERSON

[The Road To...]

Bisogna tener conto che Manuela potrebbe voler/dover passare un file allo SpatialBundle per poterci operare sopra.
Potrebbe operare in questa direzione trascinando il file sullo SpatialBundle oppure passare in qualche modo il parametro a linea di comando o tramite un'associazione MIME esempio:

$ioGftp ftp://manuela@ftp.infodomestic.com

In questo caso lo SpatialBundle deve essere in grado elegantemente di poter prendere qualsiasi parametro $1 in ingresso conservarlo gelosamente e portarlo all'attenzione del CrossBundle ed in particolare del file ultimo eseguibile in questo caso in:

/Programs/ioGftp/Linux-ix86/bin/gftp ftp://manuela@ftp.infodomestic.com

Questo comporta che lo SpatialBundle rende accessibile globalmente la $1 esportandola definitivamente a runtime per i sottoprocessi con un comando del tipo:

export $PayLoad=$1

da quel momento in poi qualsiasi script puo conoscere il valore del $PayLoad inteso come carico da assegnare al CrossBundle (inserire in SpatialBundleToDo)

[The Road To...]

Il rispetto del versioning avviene in compilazione dove il compilato deve rispettare il prefix contenendo anche il numero di versione.
Questo processo è potenzialmente indipendente dal nome dello SpatialBundle il quale è un file nominabile come si vuole.
Esempio:
Compilazione con
$./configure --prefix=/tmp/Programs/ioWine0.9.8/Linux-ix86
e SpatialBundle di nome
ioWine

Per questa ragione è opportuno inserire con precisione il numero di versione nel file ioWine0.9.8_SpatialFactory.sh tale da permettere al builder di sapere dove costruire il dinamic disk cache.

In questo modo si puo aggirare il problema di necessaria sincronia tra il nome dello SpatialBundle che segue regole di apparenza e il nome della destinazione compilata che segue la coerenza di versioning per evitare conflitti.

Di conseguenza è possibile avere anche 4 file SpatialBundle di nomi vari e puntare allo stesso programma con 4 versioni differenti.

Esempio di differenze tra /tmp/Programs/ioJava1.4 e /tmp/Programs/ioJava1.5 con eventuali SpatialBundles di nome ioJava e ioJava2

Cestino in Nautilus

Sarebbe interessante integrare il cestino in Nautilus tale che sia piu immediato cancellare un file semplicemente trascinandolo nel cestino della finestra attiva.
L'uso del cestino nel Desktop necessita un ulteriore movimentazione e disposizione delle finestre per permettere il trascinamento.
Mentre l'uso del cestino nella barra necessita di un icona di dimensioni maggiori rispetto a come viene presentata la bottom bar in Ubuntu.

Vorrei vedere se è possibile integrare il Cestino nell'elenco dei Device e non in quello dei Bookmark del riquadro laterale delle Risorse a sinistra.

Di seguito una patch dalla comunita:

http://mail.gnome.org/archives/nautilus-list/2007-March/msg00095.html

Un metodo molto banale consiste in:

Creare un bookmark alla cartella $HOME/.Trash di nome Cestino.
Cambiare icona alla cartella $HOME/.Trash e metterci un cestino.

A questo punto il bookmark compare nel riquadro laterale con la dovuta icona e pronto a ricevere dati da cancellare.


Bisognerebbe eliminare il tasto di chiusura del riquadro.E' un elemento non utilizzato dalle mie "Personas" (su Wikipedia).

Mi aspetto che eliminando il pulsante di chiusura abbia come conseguenza una maggiore pulizia dell'interfaccia visuale e sopratutto evita uno stato di inconsistenza visuale quando anche per errore (casi di click isterico) il riquadro laterale venga chiuso inavvertitamente.
Il mio utente geek test di riferimento risponde dicendo che è sufficiente andare in Visualizza->Riquadro Laterale oppure premere F9.
Ma rispondo che sono due funzioni nascoste e che Manuela deve essere istruita (aumento del carico cognitivo) e che cio comporta il trasferire il carico di memorizzazione dal mondo esterno (l'interfaccia che si osserva direttamente) alla memoria interna (la memoria del nostro cervello).

Test eliminazione tasto "Chiudi" dalla barra della finestra

Nelle mie osservazioni ho notato che Manuela e Barbara (Personas) tendono a confondersi sulla scelta per chiudere l'applicazione usando o il tasto di chiusura finestra o la voce "Esci" dal menu dell'applicazione.
La scelta di Mac OSX è quella di dividere le funzionalita tra gestione manipolazione applicazione (finestra) e gestione applicazione cosi che se chiudo la finestra l'applicazione rimane aperta ma minimizzata mentre se Chiudo l'applicazione viene chiuso tutto.
A mio avviso, nonostante apparentemente razionale, la scelta è piuttosto fuorviante perche ancora oggi viene svolta una scelta da geek tecnologo!!! Dove l'istituzione "Finestra" <> "Applicazione" la fa da padrona.
Nella pratica non è cosi per il 99% dei casi.
Una finestra = Una applicazione tale che la sua manipolazione spaziale ad oggetti deve fornire un feedback consistente di completa integrita.
L'utilizzatore vede un oggetto (Finestra + applicazione in essa contenuta) e lo considera, come le cose nella realta, un oggetto unico composto da attributi (dati vari) e metodi (funzionalita varie).
Con questa premessa nei casi generali ci si ritrova ad avere una duplicazione di una funzionalita chiave quale quella della chiusura dell'applicazione (sia tramite il pulsante di finestra sia tramite la voce del menu dell'applicazione File-> Esci).
Cio comporta confusione specialmente nei casi dove l'applicazione tende a rimanere inconsistente se viene chiusa (dicesi bruscamente) dal pulsante della finestra.
La mia visione sarebbe quella che il gestore di finestre sia finemente integrato con l'applicazione stessa tale che l'azione di chiusura dal pulsante della finestra sia una reale chiamata equivalente alla voce File->Esci o File->Chiudi o File->Quit dell'applicazione.
Da oggi testo sulla mia pelle la completa eliminazione del comando di chiusura della finestra per cercare di notare operativamente gli attriti cognitivi durante un quotidiano utilizzo.

Da questo momento sarò costretto ad usare la voce di menu per chiudere l'applicazione.
Nel caso dovessi trovare difficolta per qualche applicazione che non prevede la voce allora posso far riferimento all'uso del tasto destro (AAAAarrrgh!!)