FidocadJ e aggiunta nuovi componenti

[DarwinNE]

Ok, allora se compare nella 0.24.1, compilate un bug report, così non mi dimentico di trattarlo:

https://sourceforge.net/p/fidocadj/bugs/

[elettrodomus]

Fatto. Aggiungo che forse accade quando i simboli sono solo "testuali", mi è parso di ricordare che mi fosse già successo.

[phylum]

mmm se prendo

[080 Resistore]
LI 100 100 102 100
LI 108 100 110 100
RV 102 98 108 102

[081a bugResistore]
LI 108 100 110 100
RV 102 98 108 102

[081b bugResistore]
RV 102 98 108 102

[081c bugResistore]
LI 100 100 102 100

[081d bugResistore]
LI 108 100 110 100

[phylum]

mmm se prendo

Codice: Seleziona tutto

[080  Resistore]
LI 100 100 102 100
LI 108 100 110 100
RV 102 98 108 102

[081a  bugResistore]
LI 108 100 110 100
RV 102 98 108 102

[081b  bugResistore]
RV 102 98 108 102

[081c  bugResistore]
LI 100 100 102 100

[081d  bugResistore]
LI 108 100 110 100

sono tutti selezionabili tranne 081b e noto che:
a) - il quadrato rosso in tutte quelle che funzionano è nella stessa riga di almeno una primitiva
b) - la primitiva toccata è una linea semplice

allora provo una macro con un rettangolo e una linea anche puntiforme fuori e... FUNZIONA {quindi a) non serve} anche se la linea è lontana dal rettangolo, il rettanglo da solo no - devo cliccarlo separatamente, di b) mi basta l'esistenza della linea (traslando il rettangolo il problema rimane)

bb.PNG (2.78 KiB) Osservato 4809 volte

un altro caso

aa.png (739 Byte) Osservato 4811 volte

due rettangoli di uguali dimensioni il primo è una macro e pertanto ha un solo punto di controllo, quello sotto è il rettangolo-primitiva, con la selezione a rettangolo intercetto solo il secondo - che tocchi o meno entrambe le maniglie

comunque sembrano essere affetti solo i rettangoli e le stringhe - ho provato con tutte le altre primitive e con combinazioni esotiche e tutto va bene

[phylum]

Ho aggiornato il jar con un possibile fix al problema
Ho aggiunto anche il supporto per la modifica di librerie e categorie

[elettrodomus]

Perfetto!

Sorgente FidoCadJ | Ingrandisci | Cos'è Fidocad

[phylum]

Grazie!


C'è una novità... arriva il menu' lingua (sperimentale) ;)

[DarwinNE]

Per scegliere la lingua dell'interfaccia? Uhm, su quello non sono mica d'accordo. Non vedo nessuna ragione per usare una lingua diversa da quella indicata dal sistema operativo, a meno di non voler fare dei test o avere esigenze particolari. In quel caso, c'è l'opzione da linea di comando:

https://sourceforge.net/p/fidocadj/feature-requests/27/

[phylum]

beh non è che tutte le caratteristiche che aggiungo a fido_mod debbano passare nel ramo principale :)

- pur mantenendola, commentando 1 sola riga diventa invisibile per l'utente
- è implementata tramite introspezione (trova i MessagesBundle_XX.properties nel jar e crea il menu, riconoscendo XX)
- non serviranno quindi aggiornamenti qualora si aggiungessero altre lingue)

per l'opzione: si - ma non tutti gli utenti ne sono capaci
in sostanza: vedo più pros che cons

[DarwinNE]

Ieri sera avevo scritto una risposta articolata, ma vedo che il post non è passato. Cerco quindi di riassumere brevemente quello su cui ero arrivato.
Il punto è che quando si fa il design di un'interfaccia utente, bisogna riflettere molto attentamente alle scelte che vanno proposte all'utente. Infatti, una scelta implica un certo tempo per decidere e questo è un fatto sempre negativo perché toglie tempo ad altre attività più produttive che l'utente potrebbe svolgere con il programma. In altre parole, troppe scelte distolgono dall'obbiettivo.
Ovviamente, ci sono delle situazioni in cui le scelte sono inevitabili: bisogna per forza proporle, ed il tempo che si perde a rispondervi viene compensato dai benefici che si ottengono da una maggiore flessibilità raggiunta del prodotto, ma un costo esiste sempre.
In nome di un approccio minimalista che ho tendenza a seguire nel design, bisogna quindi cercare di ridurre il più possibile le scelte inutili, per permettere all'utente di concentrarsi verso quello che vuole realmente fare.
La proposta che elettrodomus ha fatto recentemente è qualcosa che segue questo principio: si può separare in due il copia/incolla, uno tradizionale ed uno che separi in componenti le macro non standard. Implementandolo, FidoCadJ potrà fare a meno di un'opzione di configurazione ("Suddividi le macro non standard durante il copia/incolla") per la quale una scelta nel passato (fatta nella configurazione del programma) ha ripercussioni in futuro (nel momento in cui viene fatto il copia/incolla), senza peraltro mostrare chiaramente qual è la modalità di funzionamento del programma.

Ora, il motivo per cui non sono d'accordo ad inserire una scelta per le lingue è il fatto che in un uso normale non c'è nessuna ragione pratica per avere un programma in una lingua diversa dal sistema operativo. Se qualcuno ha il sistema in inglese, è per sua scelta (e d'altronde con MacOSX cambiare la lingua richiede pochi click e forse neppure un riavvio). Quindi in virtù della stessa scelta, non vedo perché FidoCadJ non dovrebbe apparire con un'interfaccia in inglese.
L'unica ragione per cui uno può voler cambiare la lingua è per fare dei test. In quel caso, tutto è descritto dal manuale e non è una gran pena utilizzare l'opzione -l che è fatta proprio per questo.

Profondamente diverso è il caso in cui FidoCadJ gira su un sistema operativo in inglese e mostra l'interfaccia in un'altra lingua. Dopo un po' di riflessione (molto recente), credo che sia quello di cui ci si lamenta in questo ticket, registrato incorrettamente come feature request:

https://sourceforge.net/p/fidocadj/feature-requests/27/

Il problema è che c'è forse un vero e proprio bug nella scelta della lingua che non si allinea al sistema operativo. Un bug non lo si risolve mai aggiungendo un'opzione, ma appunto correggendolo ed eliminando il problema alla base.

Tempo fa, avevo trovato una traduzione di un articolo inglese sulle interfacce utente sul Pluto Journal, ma sembra che questa rivistina online (un tempo dedicata agli utilizzatori Linux) non esista più. Non mi ricordo bene quale sia l'articolo originale, ma cercandolo ho trovato questo, più recente, che mostra alcuni problemi ed alcune trappole su cui è meglio non cadere:

http://www.mpt.net.nz/2012/06/why-free- ... usability/