Screen rotation

[Meluste]

beh, SMS e home gli avevo fatti separati perchè erano quelli che potevano avere un comportamento speciale...

[maurelio79]

Esatto.
Però vedi, io non ho conoscenze tecniche, quindi ad esempio non so:

sviluppare una home che segua gli accelerometri e che quindi si disponga bene sia a 480x640 che a 640x480, richiede una complessità di programmazione di molto maggiore?

Un'altra cosa che non so, ad esempio, se uno scrive una app, deve scriverla 2 volte in modo che renda bene sia in Portrait che in landscape o basta avere un pò di accortezza in fase di programmazione per fare un lavoro decente? Se ad esempio nella app inserisco 4 righe che leggono gli accelerometri per capire come cavolo è orientato sto telefono e in base a quello che legge, si avvia con un layout piuttosto che un altro, si appesantisce di molto l'esecuzione della app?

[Arus]

Esatto.
Però vedi, io non ho conoscenze tecniche, quindi ad esempio non so:

sviluppare una home che segua gli accelerometri e che quindi si disponga bene sia a 480x640 che a 640x480, richiede una complessità di programmazione di molto maggiore?

Un'altra cosa che non so, ad esempio, se uno scrive una app, deve scriverla 2 volte in modo che renda bene sia in Portrait che in landscape o basta avere un pò di accortezza in fase di programmazione per fare un lavoro decente?

Queste cose ci sono già(tranne l'uso degli accellerometri), per disporre gli oggetti in land e portr si usano gli xml....

Vi siete scordato il problema principale: il tempo di rotazione.
Dobbiao bloccare necessariamente nde, home, launcher ecc, così da poter avere libertà sulle altre app. Come fate a ruotare con gli accellerometri se ci vogliono(essendo ottimisti) 10 secondi??
 

[nicola.mfb]

Ok, inseriamo una nuova variabile.
Supponiamo di essere in landscape con un terminale o un browser, arriva una telefonata, cosa succede?
La app telefonica dovrebbe venire in primo piano e mostrare il numero che ci sta chiamando, se poi rispondiamo dovrebbe venire fuori la "call status window" con durata, vivavoce, volumi etc.
Che facciamo? ruotiamo appena arriva la chiamata? siamo pronti ad accettare qualche secondo di delay?
o cosa?

    Niko

[maurelio79]

Ma io non capisco una cosa: i tempi così lunghi, sono causati dall'HW o dall'implementazione software?

siamo pronti ad accettare qualche secondo di delay?

Dipende cosa intendi per qualche secondo.... 2/3 secondi oppure 10 secondi? 

[nicola.mfb]

No ho ancora avuto il tempo di testare un rotate puro senza resize, ma suppongo si tratti di 2/3 secondi al max, o anche meno.
Infatti se la finestra del dialer è già aperta a 480 x 640 e nascosta, si tratterebbe di fare un rotate del display ed un "raise" senza fare alcun resize di alcuna applicazione. Sarebbe quello che fa maemo, con l'effetto di rotazione in 3d che noi non possiamo permetterci, ma che fatto "secco" spero davvero possa impiegare pochi secondi.
Il problema è che in passato molta gente si lamentava del fatto che fso ed il resto delle app telefoniche, poichè scritte quasi tutte in python comportavano un delay di diversi "squilli" prima che apparisse la finestra di incoming call, + qualche secondo per accettare la chiamata, e che quindi, il tempo per rispondere prima che l'altro "desistesse", fosse più corto che con un normale telefono.
Ora, poichè non ho mai usato il freerunner seriamente come daily phone, non so se questo delay è in effetti + o - tollerabile.

[Arus]

Un delay di un 1-2 sec si verifica più o meno sempre: ad esempio se usi un'applicazione ci mette anche 2-3 sec, ma non mi è mai capitato di più e ormai lo uso daily da un mese. Questo con qtmoko.
Potrebbe essere seccante in alcuni casi avere qualche altro secondo di delay, ma alla fine va provato sul campo prima di allarmarsi, anche se un incoming call è un evento importante!
Perchè non blocchiamo la parte che, bene o male all'unanimità, abbiamo pensato di sacrificare in portrait-only? Così discutiamo su qualcosa!

[Meluste]

per la chiamata, io dico che la finestra che ci segnala una chiamata in entrata la si fa di 480 x 480 centrata in 0,0 in questo modo, la si ha senpre ben visibile senza dover ruotare niente e non avere delay.
meglio ancora, la si fa 640x640 con le due fette destra e in basso che riportano i comandi stile "accetta" rifiuta" in sovrabbondanza:
se siamo in port. abbiamo nel quadrato 480 x 480 le info del contatto, e in basso i due o tre pulsanti. dato che in land, questi pulsanti verrebbero fuoriu dallo schermo, ne mettiamo altri tre uguali nella parte a destra del quadrato 480 x 480.
Stessa cosa per gli SMS in arrivo e altre notifiche simili

poi, una volta che ho premuto "rispondi" aspetti tre secondi prima di ruotare, durante i quali mi mandi una scritta che mi dica che la chiamata è in corso.

Mi spiego?

[Arus]

Secondo me può andare bene in 640x640, poi i dettagli si sistemano con calma. L'importante è evitare il delay e avere lo possibilità di capire se la chiamata è attiva o meno.

[nicola.mfb]

Umh... ricordiamo che la "status window" è un pò collegata a tutta la app telefonica, durante una chiamata dobbiamo poter inviare, ad esempio, toni dtmf, e quindi visualizzare il dialer.

[Meluste]

io dico che la "status window" può apparire anche con un ritardo di anche 5 secondi dopo che la conversazione è stata accettata, quindi si ha tutto il tempo per ruotare lo schermo e far apparire il dialer e tutto il resto in port, come dovrebbe essere.
Quello che invece dovrebbe apparire subito sono:
la finestra "chiamata in arrivo" con "accetta, rifiuta"
una cosa qualsiasi (non per forza la status window) che mi dica che la chiamata è stata accettata o rifiutata... diciamo una "status window provvisoria": questa può essere anche solo una scritta che appare a shermo intero con sfondo verde o rosso, a seconda...
Poi, una volta avviata la conversazione, diciamo dopo due - tre secondi dall'accetta, si gira lo schermo e si fa apparire la "status window" vera e propria, con possibilità di dialerr per il DTMF, chiamate multiple, volume, ecc...