On Fri, 2010-05-28 at 17:54 +0200, Andrea Gasparini wrote: > Benone! > > Allora, io sto guardando invece come prendere dall'SVG i dati relativi a un > oggetto. > Quel che vorrei fare in pratica è: dato un id="" di un pezzo dell'SVG, > dovrei riuscire a dare in output la posizione e la rotazione che poi verrà > usata dall'apps.py per visualizzare il tutto.
Quello che vedo è che per determinare come un oggetto è ruotato controlli le trasformazioni che sono state applicate. È ottimo: ti basta fare la tua presentazione in Inkscape, ruoti tutto come vuoi e A4 sa già cosa fare. Mi dispiace fare sempre la figura del rompiballe, ma se io volessi vedere di proposito una scritta di traverso? Prova ad aprire il file che ho allegato (che è un esempio sufficientemente realistico di quella che potrebbe essere una presentazione). Se vedi in alto, la scritta "Calo delle vendite" è ruotata, ma ciò non significa che la vista debba ruotare necessariamente. Se guardi un po' più in basso, c'è anche una lettera "A". Guardando il codice del file ti accorgi che quella lettera non è un <text> ma un insieme di linee *non ruotate*. Nonostante ciò la vista dovrebbe ruotare. Anch'io ieri ci pensavo e anch'io sono caduto il quel tranello. Quello che proporrei io è di mettere le informazioni riguardanti le rotazioni tra i metadati. In questo modo non si hanno vincoli e il codice risulta anche più semplice da scrivere (perché non devi frugare tra l'XML e fare calcoli complicati). L'unico problema che ho individuato è che in assenza di un editor, un utente avrebbe più codice da scrivere, ma questo è un problema solo temporaneo. Se l'idea piace, avrei qualcosa da aggiungere alla proposta. > Secondo me è anche il caso di dividerci un pelo i lavori, altrimenti > rischiamo di far due volte la stessa cosa: io vorrei finire di tirar fuori > i dati dall'SVG. Andrea Gualano ha espresso volontà di occuparsi delle > funzioni di animazione. > Dite un po' quel che pensate. Io sono abituato a lavorare in questo modo: mi faccio un piccolo plan di quello che ho intenzione di fare, poi faccio tanti piccoli branch e li invio uno alla volta (mandando anche una mail in ML, se una discussione è necessaria). Il vantaggio di questo workflow è che per ognuno è più facile discutere le decisioni: il codice c'è, è poco e quindi leggibile e le intenzioni sono specificate nella merge proposal. Lavorare ognuno nel proprio maxi-branch mi sembra un po' complicato: si creano conflitti con il trunk, è più difficile capire dove bisogna guardare e così via. Leggendo le mie proposals avete avuto dei problemi o dei dubbi? Credete che debba migliorare qualcosa? Sarei veramente lieto di sentire i vostri commenti sul mio workflow. Thanks, Andrea
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~a4-dev Post to : a4-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~a4-dev More help : https://help.launchpad.net/ListHelp
