Collaborate allo sviluppo FidoCadJ!

[Stemby]

La directory jar/ non sarebbe meglio se fosse vuota, su Git?

Lo dico in quanto in genere i file binari non sono ben visti tra i sorgenti, per almeno tre ragioni:
1) Git li gestisce male
2) Occupano spazio e banda inutilmente
3) Nella pacchettizzazione per le varie distro GNU/Linux tendenzialmente tutto deve essere generato a partire dai sorgenti

Ciao!

[DarwinNE]

Fatto. È stato più impegnativo di quanto avessi inizialmente immaginato...

Eh, scrivere o revisionare la documentazione porta via moltissimo tempo. Molti la trascurano, ma secondo me è un errore grave, perché è in fondo la prima cosa che viene letta da qualcuno che si voglia interessare più a fondo del progetto.
Comunque, ho visto le pull request e le ho approvate, andavano benissimo!

Prossimo passo: revisione del manuale!

Bravo! Per il momento, non ho lavorato al manuale. Quello che prevedo in un futuro più o meno prossimo è:
- terminare il codice relativo all'anteprima di stampa
- descrivere l'anteprima di stampa nel manuale in inglese (ci sono cosette interessanti da raccontare sui margini, la zona stampabile etc.)

Nel frattempo, sempreché a te interessi, ti proporrei di dare un'occhiata al manuale in inglese e vedere se le informazioni sono aggiornate oppure no, se ci sono errori di ortografia o grammatica, oppure se ci sono lavori poco chiari (per esempio la parte su Linux di cui abbiamo già discusso).
Non dico certo di revisionare tutto il manuale come hai fatto con i README, ma semplicemente se vedi cose strane annotatele e fammi sapere

Poi se qualcuno (non te per forza) volesse dare una mano con la traduzione in italiano, lancio un appello: c'è questa Issue sempre aperta https://github.com/DarwinNE/FidoCadJ/issues/49

[DarwinNE]

La directory jar/ non sarebbe meglio se fosse vuota, su Git?

Sarei tendenzialmente d'accordo e per un po' ho lavorato così. Tuttavia in passato non tutti quelli che erano in grado di scaricarsi i sorgenti con svn sono riusciti a compilare il programma ed ad ottenere un file jar per conto loro. Mi pare che per questa ragione, alla fine, ho finito per fare un svn add là dove non era strettamente necessario

Dai: piattaforma nuova, sistema di controllo di versione nuovo, vita nuova! Adesso vado di git rm
EDIT: però solo su fidocadj.jar, perché è una GRAN COMODITA' avere a disposizione le librerie di Quaqua sempre a portata di mano.

Ne approfitto anche per aggiungere il tuo nome nel paragrafo 6 del README

[Stemby]

Ne approfitto anche per aggiungere il tuo nome nel paragrafo 6 del README

Grazie mille!

però solo su fidocadj.jar, perché è una GRAN COMODITA' avere a disposizione le librerie di Quaqua sempre a portata di mano.

Se ho ben capito Quaqua serve solo per MacOSX, giusto?

Ciao!

[DarwinNE]

Se ho ben capito Quaqua serve solo per MacOSX, giusto?

Sì, è così. Si potrebbero forse mettere i file necessari in una cartella lib/ e poi lo script compile provvederebbe a copiarli in jar/ se necessario.

[Sjuanez]

Oggi ho visto spuntare questo e mi sembra una buona idea:

https://github.com/danielcgold/10-minute-tasks

Magari ci sono altri esperimenti simili, più popolari, e possono tornare utili al progetto.

[Stemby]

Sì, è così. Si potrebbero forse mettere i file necessari in una cartella lib/ e poi lo script compile provvederebbe a copiarli in jar/ se necessario.

Mmm, non cambierebbe niente: resterebbe comunque un binario gestito da Git; si andrebbe solo ad aggiungere una cartella e a complicare inutilmente lo script.

Ci ragiono un attimo e vedo se trovo qualche soluzione.

[Stemby]

DarwinNE, qualcosa del genere potrebbe andare?

1) aggiungere jar/quaqua.jar in .gitignore
2) rimuovere jar./quaqua.jar da Git
3) caricare da qualche parte (basta che sia affidabile) quaqua.jar
4) modificare lo script compile per fare qualcosa di questo tipo:

Codice: Seleziona tutto

SE sistema_operativo È macosx:
    SE quaqua.jar NON È IN jar/:
        wget https://[...]


In questo modo, se il file è già presente nel proprio repo Git locale tutto continua a funzionare come ora; in alternativa alla prima compilazione il download avviene in automatico per gli utenti MacOSX (che sono gli unici interessati).

Cosa ne pensi?

[DarwinNE]

Tendenzialmente sarebbe una buona soluzione, però avrebbe il difetto di includere una dipendenza in più nel progetto, il che non mi rende proprio entusiasta.
Il sito ufficiale di Quaqua è qui:

http://www.randelshofer.ch/quaqua/

comunque, secondo me sarebbe comunque meglio tenere le librerie da qualche parte nel repository, per esempio in OSes/mac, anche perché nessuno ci assicura che non venga fuori un giorno una versione buggosa di Quaqua, oppure, peggio, il sito non venga piratato.

Comunque, per quanto riguarda la compilazione di fidocadj.jar, attualmente c'è un "quasi" problema. Se questa viene effettuata su un sistema operativo MacOSX, viene compilata ed inclusa la classe AppleSpecific che si occupa di migliorare leggermente l'integrazione fra il programma e MacOSX. Dopotutto, c'è stata un'epoca lontana in cui i programmi in Java erano molto benvenuti su MacOSX.

Se la compilazione viene fatta su un altro sistema operativo, questa classe non viene compilata (perché non è compilabile) e non viene inclusa. Il programma parte lo stesso e funziona perfettamente, ma manca il codice che ne garantisce una buona integrazione con MacOSX. Questo è gestito in maniera abbastanza trasparente.

Pertanto, il file fidocadj.jar destinato alle versioni da distribuire (o da pacchettizzare nella versione specifica per MacOSX) dev'essere, per ottenere i migliori risultati, compilato con MacOSX, a meno che non si sia assolutamente certi che non verrà mai eseguito su questo sistema operativo.

[Stemby]

Ho visto le ultime modifiche

Una cosa: i test mi sembra di capire che funzionino solo sui sorgenti java. Non c'è modo di tenere verificati anche altri contenuti?

Ad esempio in bin/ ci sono 4 file che usano ancora come fine riga LF+CR. (tra l'altro, come mai i file *.properties stanno in bin/, considerando che non sono binari?)

Tendenzialmente sarebbe una buona soluzione, però avrebbe il difetto di includere una dipendenza in più nel progetto, il che non mi rende proprio entusiasta.

Capisco, ma in effetti si tratta a tutti gli effetti di una dipendenza, che poi può essere gestita in vari modi.

comunque, secondo me sarebbe comunque meglio tenere le librerie da qualche parte nel repository, per esempio in OSes/mac

Ok. In ottica pacchettizzazione per le distro GNU/Linux, se viene zappata per intero la directory OSes non succedono danni, vero?

Colgo l'occasione per chiedere una cosa notata giorni fa: in fase di compilazione con OpenJDK 7 ottengo alcuni warning. Ne sei a conoscenza? Ti interessano?

Ciao!