FidocadJ e aggiunta nuovi componenti

[DarwinNE]

uso: scopritelo! è mooolto semplice

Ci ho provato, ma...

Codice: Seleziona tutto

[davidebucci@davide-bucci-portable]$ java -jar fido_mod.jar
Exception in thread "main" java.lang.UnsupportedClassVersionError: FidoMain : Unsupported major.minor version 51.0
   at java.lang.ClassLoader.defineClass1(Native Method)
   at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
   at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
   at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
   at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
   at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
   at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
   at java.lang.Class.forName0(Native Method)
   at java.lang.Class.forName(Class.java:247)
   at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:56)
[davidebucci@davide-bucci-portable]$ java -version
java version "1.6.0_37"
Java(TM) SE Runtime Environment (build 1.6.0_37-b06-434-10M3909)
Java HotSpot(TM) Client VM (build 20.12-b01-434, mixed mode)
[davidebucci@davide-bucci-portable]$


[GaAsFET]

No, per quello niente. Infatti sarebbe indispensabile lavorare con netlist (e FidoCadJ non lo fa) e mettere a punto delle biblioteche di componenti. Ci sono già altri programmi che lo fanno, non è il caso di fare diventare FidoCadJ una brutta copia di Altium Designer...

E chi l'ha detto che sarebbe una brutta copia ??

Per quanto riguarda fidomod.jar, anche a me fa indispettire la jvm:

Codice: Seleziona tutto

Exception in thread "main" java.lang.UnsupportedClassVersionError: FidoMain : Unsupported major.minor version 51.0
   at java.lang.ClassLoader.defineClass1(Native Method)
   at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
   at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
   at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
   at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
   at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
   at java.lang.Class.forName0(Native Method)
   at java.lang.Class.forName(Class.java:264)
   at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:56)

Credo sia un problema legato alla compilazione delle classi con un determinato JDK, nello specifico troppo avanzato rispetto a quello che uso io (jre 1.6.0).

[elettrodomus]

Attualmente l'ordine dei simboli (e delle sottocartelle) che si presenta a destra, nelle directory "ad albero", è dato dall'ordine alfanumerico dei tag dei simboli. Tant'è che se uno che fa una libreria e vuole seguire un ordine in quello, deve valutare anche che tag utilizzare per il simbolo. Sarebbe interessante poter ovviare in qualche modo a questo.

Non ho avuto tempo di provare per bene il lavoro di phylum, ma l'interfaccia mi sembra molto buona

[phylum]

riguardo alla versione, il fatto è che stavo facendo più cose insieme è l'ho compilato java7 min e le impostazioni di un altro progetto :P

L'idea è questa:

step1.png (14.7 KiB) Osservato 4689 volte

step2.png (6.97 KiB) Osservato 4689 volte

step3.png (8.24 KiB) Osservato 4688 volte

Quest'ultima finestra simula l'effettiva creazione e l'aggiunta alla libreria che per ora non c'è, la parte selezionata è automaticamente rimossa dal circuito corrente ed eventualmente il nuovo componente è automaticamente inserito al suo posto dopo essere stato salvato nella libreria.

Ci sarebbero da fare alcune modifiche:
- ho visto che se una libreria si chiama come una esistente la rimpiazza, io pensavo piu' a un file di integrazione - p.es se voglio aggiungere un simbolo a PCB Footprints - sarà generato un _pcb_footprints.fcl nella cartella del programma che contiene solo i nuovi - il resto rimane nel jar dove è ora - e se un utente vuole condividere la creazione invia il .fcl a DarwinNE

- le coordinate che vedete non sono ri-basate

- la lista al momento è popolata con id - ci andrebbero le descrizioni, con p.es le seguenti "convenzioni"
nella lista appare libreria.gruppo e selezionandola il campo gruppo si compila automaticamente oppure librerie e gruppo sono due combo - e nel caso l'utente abbia già selezionato un simbolo nell'albero a destra - libreria e gruppo sono già impostati su quella

- nell'albero aggiungere Elimina simbolo/Sposta simbolo

- eventualmente un controllo simbolo già esistente

[GaAsFET]

riguardo alla versione, il fatto è che stavo facendo più cose insieme è l'ho compilato java7 min e le impostazioni di un altro progetto :P

Pensi mica di rilasciare anche una versione per java6 ?

[phylum]

of course, a livello di codice basta 1.4.2 mentre fido vuole 1.5 per cui nessun problema - ma non sono nemmeno sicura di poter continuare io il progetto :) dipende dal tempo a disposizione - insomma l'esempio sopra è da considerarsi più un concept che qualcosa di concreto

[GaAsFET]

Grazie cara

Intanto complimenti per l'impegno... se avessi più tempo a disposizione, mi candiderei come aiuto

[DarwinNE]

Bravi ragazzi, continuate così!

Le idee sono interessanti. Se le riassumo, a grandi linee:
- la funzione di database dei simboli è svolta in associazione con l'albero già presente a destra
- la creazione di un nuovo simbolo avviene selezionando un elemento e specificando i dati che mancano

Ora mi rimangono delle domande:
1 - come fare per modificare simboli già esistenti? Io non amo utilizzare i "modi" in un'interfaccia utente. FidoCadJ ne fa comunque uso perché si allinea con la quasi totalità dei software di disegno, tuttavia non vorrei aggiungerne altri (tipo, adesso modifichiamo il componente xyz):

http://en.wikipedia.org/wiki/Mode_(computer_interface)

2 - come la specifico l'origine del componente?

3 - come differenziare le librerie standard da quelle aggiunte dall'utilizzatore?

4 - c'erano delle idee interessanti suggerite da Candy sull'includere dei simboli nei disegni (vi lascio cercare, ne ha parlato qui su EY e su Sourceforge). In che misura si possono mettere in atto?

Tenderei ad evitare quando possibile l'utilizzo di finestre di dialogo che appunto spesso sono modali. Da questo punto di vista, credo che ci sia spazio per miglioramenti anche nel FidoCadJ attuale.
Per adesso non mi interessano gli aspetti tecnici (tipo come chiamare un nome di un file), ma gli aspetti di interfaccia e di filosofia. Ho visto che quando il design è pulito, l'implementazione richiede di solito poco sforzo.

P.S. L'approccio minimalista è anche dovuto al fatto che... quando aggiungo una stringa all'interfaccia utente, c'è da tradurla in 7 lingue! Passo molto tempo a descrivere che traduzioni fare ed ad allertare i traduttori che gentilmente si occupano della cosa:

https://sourceforge.net/p/fidocadj/disc ... /9d08d94d/

Non parliamo poi del manuale... Ormai FidoCadJ è un progetto avviato, ed il lavoro sul codice è solo una piccola parte del necessario.

[DarwinNE]

phylum, tu credo che adesso abbia accesso in scrittura al repository.
Se hai codice da mostrarmi, fai un "svn cp" da trunk a "branches/phylum2" e prova a lavorare lì dentro. Occhio solo che io non uso Eclipse, ma un editor di testo generico (qualche volta anche solo vim), quindi c'è da rimanere compatibili (vedi il file README per più d'informazioni).

[phylum]

1. io direi semplicemente di non-farlo, al piu' cliccando su una macro (simbolo) una voce es. "Usa come modello" lo aggiunge come testo al circuito (invece che come macro) e l'utente puo' salvarlo modificato tra i suoi custom ed eventualmente permettere l'eliminazione del componente di origine taggandolo "cancellato" p.es senza cambiare sintassi & co ci si mette un . come per i file nascosti di linux all'inizio del nome

3. mah non credo sia indispensabile differenziarle, l'utente medio avrà al piu' 1-2 librerie custom (e avevo previsto di poter dare un nome alle librerie create mentre nella demo è fissato a Custom) e apporterà qualche modifica a un paio di componenti esistenti - i simboli "promossi" faranno già parte delle future versioni

4. ricerca in progress :P

Finestre beh, nello scenario 2 che avevo previsto (una libreria e un gruppo selezionato nell'albero) l'input mancante è solo il nome - volendo rendere ancora più rapida la creazione (per l'utente) il nome può essere settato di default a nuovo_simbolo e poi si accede alla finestra per cambiarlo ma potrebbe anche essere più scomodo - oppure la scelta della libreria/gruppo fatta tramite sotto menu di converti stesso

Codice: beh quello che volevo mostrare era l'idea - il codice, ad eccezione della finestra presa in prestito, è inferiore a 20 righe :P